SGS'nin Yedi Seviyeli Navigasyon Sistemini Yeniden Tasarlamak: Bir Vaka Çalışması

SGS (eski adıyla Societe Generale de Surveillance ), 14 sektörde küresel bir hizmet organizasyonu ve denetim, doğrulama, test ve belgelendirme hizmetleri sağlayıcısıdır. SGS'nin web sitesi (60 yerelleştirilmiş web sitesiyle birlikte) öncelikle organizasyonun temel hizmetlerini tanıtmanın yanı sıra çok sayıda faydalı hizmete, ek içeriğe ve araca erişim sağlar. Amacımız, sgs.com'u yalnızca masaüstünden duyarlı olmaya dönüştürmekti.

Bu, özellikle yedi seviyeye kadar derinlikte olan (iki bölüme ayrılmış) ve yaklaşık 12.000 bireysel gezilebilir öğeden oluşan eski navigasyon sistemi çevresinde benzersiz bir dizi zorluk ortaya çıkardı.

SmashingMag'de Daha Fazla Okuma : Bağlantı

• Vaka Çalışmaları Tasarlamak: İnsan Merkezli Tasarım Sürecini Sergilemek
• Duyarlı Bir Tasarıma Uyarlama
• Ürün Tasarımı Birleştirme Vaka Çalışması
• 75 Öğretici Vaka Çalışmaları – Biz Böyle Yaptık

SGS'nin navigasyon sistemini ilk kez gördüğümüzde ve kullandığımızda doğal tepkimiz, gezilebilir bağlantıların ve içeriğin çok büyük olması nedeniyle bilgi mimarisinin (IA) kesinlikle basitleştirilmesi gerektiğiydi. Ancak, navigasyonun bu projeden önce arama motorları ve IA için zaten optimize edilmiş olduğu ve SGS'nin birçok endüstride (içerik hacmine yansıyan) geniş bir hizmet yelpazesi sunduğu düşünüldüğünde, IA'nın yeniden düzenlenmesinin olmayacağı açıktı. çözümün bir parçası olun.

Basitçe söylemek gerekirse, gezinme ağacının yapısının bozulmadan kalması gerekiyordu. Yine de bu, iç denetimde bazı küçük ayarlamalar yapmamızı engellemedi. Örneğin, daha fazla görünürlük için “Haberler, Medya ve Kaynaklar” ve “SGS Ofisleri ve Laboratuvarları” en üst seviyeye taşındı. İlki ile, SGS'nin düzenli olarak haber yayınladığını ve etkinliklere ev sahipliği yaptığını daha net bir şekilde yansıtmak önemliydi. İkincisi ile, iletişim sayfasıyla birlikte web sitesinin yapısındaki herhangi bir yerden kolayca erişilebilir olması hayati önem taşıyordu. Bu nedenle, kilit soru, böyle bir navigasyon sisteminin farklı görünüm pencereleri arasında kolayca geçiş yapmak için hala kullanılabilirken nasıl yapılabileceğiydi?

Proje Politikalarının Oluşturulması

Sağlıklı bir müşteri-tasarımcı ilişkisi, her projenin başarısı için esastır. Etkili rehberlik sağlamanın yanı sıra net beklentiler belirlemek, yalnızca kilit paydaşların baştan sona odaklanmasını sağlamakla kalmaz, aynı zamanda proje ilerledikçe tüm taraflar arasında güvenin gelişmesini sağlar. Bu projede kesinlikle durum buydu; tüm taraflar arasındaki işbirliği ve birbirlerinin rolleri ve uzmanlıklarının karşılıklı olarak takdir edilmesi gerçekten dikkat çekiciydi.

Ancak, tüm tarafların odaklanmaya devam etmesini sağlamak için, başlangıç ​​toplantısında, içinde yaratıcılığı da kullanabileceğimiz bir dizi önemli yönerge ve gerekliliği belirledik (bazıları üzerinde ısrar ettik, diğerleri müşteri tarafından ısrar edildi):

• İçerik paritesi . İçerik her cihazda ve platformda erişilebilir olmalı ve mobil cihazlarda hiçbir koşulda gizlenmemelidir.
• Performans . Web sitesi, rakip web sitelerinden en az %20 daha hızlı performans göstermelidir. Bu, özellikle her sayfada ne kadar bilgi olması gerektiğine karar verirken faydalı oldu.
• Erişilebilirlik Web sitesi, WCAG 2.0 düzeyi AA erişilebilirlik yönergelerine uymalıdır. Şirketin markalaşması nedeniyle sınırda bir renk kontrastı sorunu dışında bu hedefe ulaşmayı başardık.
• Kullanılabilirlik Şirket içi ekibin kavramları kapsamlı bir şekilde doğrulaması ve yüz yüze ve uzaktan kullanılabilirlik testleri yapması gerekiyordu.
• Kesintisiz iş . Yeniden tasarım, şirketin işini hiç aksatmamalıdır. Açıkça görülüyor ki, görev şirketin hizmetlerini optimize etmek değil, yerleşik iş süreçlerini hesaba katarak web sitesini optimize etmekti. Örneğin, web formlarını optimize etme özgürlüğümüz vardı, ancak CRM'deki verilerin yapısının bozulmadan kalması gerekiyordu.

Üç Büyük Zorluk

Belirlenen temel yönergelerle ve navigasyonun yeniden tasarımının IA'nın önemli bir revizyonunu gerektirmeyeceğini bilerek, yeniden tasarımı üç önemli ancak birbirine bağlı faaliyet grubuna ayırdık:

• Düzen yerleşimi . Bu, çoğunlukla şirket içi ekip tarafından gerçekleştirildi, biz de iyileştirmeler önerdik ve herhangi bir kararın yeni duyarlı tasarımın diğer yönleri için radikal etkileri olmayacağından emin olduk.
• Etkileşim ve kullanılabilirlik . Bunlar üzerinde SGS'nin tasarım ekibiyle işbirliği içinde çalışıldı. Fikirler e-posta yoluyla ve yerinde çalıştaylarda paylaşıldı ve kullanıcılara, paydaşlara ve genel iş gereksinimlerine göre düzenli olarak doğrulandı.
• Performans . Bu, yalnızca bizim tarafımızdan ele alındı, çünkü daha çok teknik bir zorluktu ve yeni duyarlı web sitesini hızlı hale getirmemiz dışında herhangi bir stratejik karar alma süreci gerektirmiyordu.

Düzen Yerleştirme

Gezinme, web sitesinin boyutu veya karmaşıklığı ne olursa olsun, sayfa düzeninin temel bir unsurudur. Bu kadar büyük ölçekli bir navigasyon sistemiyle uğraşırken ekran dışı bir desen çekici görünse de, navigasyonun kullanıcı tarafından görülmediği durumlarda sorunlar olabileceğini unutmayın.

SGS'nin tasarım ekibi başlangıçta çeşitli konseptleri test etmişti çünkü sadece gezinme etkileşimini değerlendirmekle kalmayıp aynı zamanda sayfanın geri kalanıyla doğru dengeyi oluşturmak ve dağınıklığı önlemek zorundaydılar.

Konsepte Karar Vermek

Web sitesinin karmaşıklığı göz önüne alındığında, navigasyonun her zaman görünür kalması ve kullanıcıya ağaç yapısı içinde nerede olduklarını bildirmesi hayati önem taşıyordu. Kullanıcı arayüzünde navigasyonu iki parçaya bölmek yerine, yeni navigasyon sisteminin kusursuz olmasını istedik (en üst seviyeden en alt seviyelere kadar). Bu nedenle, kullanıcının gezinme ağacında kolayca yukarı ve aşağı ve ayrıca ana bölümler arasında yanlara doğru gezinmesini sağlamalıydı.

Tüm bu kombinasyonları test etmek ve doğrulamak için, ilk sekiz navigasyon konseptinin her biri için bir prototip geliştirdik. Prototipler, kurum içi ekibin zaten şüphelendiği şeyi doğruladı: Kullanılabilirlik, bakım, ekranlar arası deneyim, görsel dağınıklık ve çekicilik açısından en uygun seçenek, navigasyonun geniş ekranlarda kenar çubuğuna yerleştirilmesi ve bir araç olarak görünmesiydi. küçük ekranlarda açılır menü. Esasen navigasyon modülü, ekran boyutundan bağımsız olarak işlevsel ve görsel olarak bağımsız olacaktır.

Bir dakika içinde belirli etkileşim kararlarına odaklanacak olsak da, prototip bir konsept test edildikten ve onaylandıktan sonra etkileşimli prototiplerin mutlaka atılması gerekmediğini belirtmekte fayda var.

Akıllı Prototipleme

Prototipleri her zaman semantik, erişilebilir ve sağlam işaretleme kullanarak doğrudan HTML, CSS ve JavaScript'te geliştiririz, çünkü daha sonra tasarım sürecinde ilk prototipleri genellikle daha sonra yeniden kullanabiliriz. Bu, yeni navigasyon sistemi için ilk prototipimizin, tüm sayfa şablonlarını ve modülleri içeren nihai web sitesi prototipinin temel taşı olduğu anlamına geliyordu.

Tam prototipi teslim ederken, stil kılavuzunun SGS ekibi için otomatik olarak oluşturulmasını da sağladık. SGS'nin tasarım ekibinin tam sayfalar yerine modülleri tasarlama ve geliştirme açısından düşünmesini sağlayarak, oluşturulan stil kılavuzu çok az sürekli bakım gerektirecektir. Stil kılavuzunun kendisi, kullanılan tüm ayırt edici modüllere atıfta bulunur ve her bir modül, kesin bir açıklama, kod örneği ve kullanıldığı sayfa şablonuna otomatik olarak oluşturulan bir bağlantı içerir. Görevleri ve özellikleri otomatikleştirmek için tercih ettiğimiz teknoloji PHP'dir, ancak çıktı anlamsal HTML olduğu sürece otomasyon herhangi bir sunucu tarafı dili kullanılarak gerçekleştirilebilir. (Prototiplerimiz için özel bir dosya sistemi çerçevesi geliştirdik, ancak bu başka bir durumun konusu.) Bu makalenin ilerleyen bölümlerinde, sunucu tarafı komut dosyası oluşturmanın, gezinmenin birden çok sürümünü korumamıza ve test etmemize nasıl yardımcı olduğunu açıklayacağız.

Anlamsal, erişilebilir ve sağlam HTML ile başlamak çok önemli olsa da, "önce içerik, ikinci gezinme" ilkesi aynı derecede önemlidir çünkü gelecekteki olası istisnaları hesaba katmanıza yardımcı olur. Bu projede "önce içerik, ikinci gezinme" kuralının bir istisnası vardı: ana sayfa. Analitiklere dayanarak, gezinmenin ana sayfada en önemli unsur olarak görüldüğünü keşfettik, bu da sayfadaki herhangi bir temel içerikten önce gelmesi gerektiği anlamına geliyordu.

Etkileşim ve Kullanılabilirlik

Bağımsız, ekran boyutundan bağımsız bir navigasyon modülü tasarlamaya ve geliştirmeye karar verildikten sonra, navigasyon etkileşimlerine odaklanma zamanı gelmişti. Navigasyonu tasarlamak için mobil öncelikli bir yaklaşımı benimsediğimiz göz önüne alındığında, navigasyon modülünün kendisi yalnızca doğal olarak küçük görünüm pencerelerinde beklendiği gibi çalışmakla kalmayacak, aynı zamanda büyük görünüm pencerelerinde de çalışmak üzere kolayca ölçeklenecektir.

Üç Etkileşimli Sürüm

Navigasyonun boyutu ve potansiyel iç içe seviye sayısı nedeniyle, daha yaygın mobil navigasyon modellerinden bazılarını seçenekler olarak ortadan kaldırmak zorunda kaldık - örneğin, açılır listeleri ve öncelik+ modelini seçin. Navigasyonun üç etkileşimli versiyonunun prototipini oluşturmaya odaklandık: kaydırıcı, akordeon ve akordeon ve kaydırıcı. Her birinin, kararımızı doğal olarak etkileyen artıları ve eksileri vardır.

Akordeon

Akordeon muhtemelen mobil cihazlarda en yaygın modeldir. Kullanıcı konu veya eylemde ilerledikçe daha ayrıntılı bilgileri ortaya çıkararak aşamalı olarak ifşa eder. Ayrıca kullanıcının bunalmamasını sağlar, bu yüzden onu temel bir çözüm olarak kullanmak istedik.

İşte akordeonun artıları:

• Kullanıcılar buna aşinadır.
• Kullanıcılar, birden fazla seçeneği önizlemek için tüm gezinme ağacını genişletebilir (sonuçta yedi gezinme düzeyi biraz bunaltıcı olabilir).
• :target sözde sınıfını kullanarak JavaScript olmadan çalışır.
• Geliştirmek kolaydır.

Ve akordeonun eksileri:

• Derin seviyeli bir kategorinin genişletilmiş ataları, mevcut kapsamı ekranın üst kısmından çok uzağa itecek ve bu nedenle çok fazla kaydırma gerektirecektir.
• Yedi gezinme düzeyi, yedi temel rengin (gri) tonu, yedi tipografik hiyerarşi düzeyi veya yedi girinti düzeyi olsun, seçilen görsel işaretin yedi derecesini gerektirir.

kaydırıcı

Bu başlangıçta en sevdiğimiz çözümdü, ancak önemli bir unsuru gözden kaçırıyor: ana bölümler arasında gerçekten yanlamasına gezinmeye izin veriyor. Kullanıcı her zaman ana sayfadan göz atmaya başlarsa böyle bir sorun olmaz, çünkü ana bölümlere giderek daha fazla aşina olurlar. Ancak, gezinme ağacının derinliklerinde bir sayfaya giren kullanıcılar için bu kesinlikle bir kullanılabilirlik sorunu olurdu. Örneğin, üçüncü, dördüncü veya beşinci seviyeye inen kullanıcılar, iletişim sayfasına ulaşmak için ağaçta yukarı çıkmak zorunda kalacaktı. Kullanıcı ne kadar motive olursa olsun, yedi seviyeyi geçmek eğlenceli değildir.

Kaydırıcı profesyonelleri:

• Hiyerarşi açıktır.
• Animasyon kaygan.
• Mobil sözleşmeleri takip eder.
• Geliştirilmesi nispeten kolaydır.

Kaydırıcı eksileri:

• Yanlara göz atmak mümkün değildir.
• Animasyon performans göstermiyor.

Hibrit (akordeon ve kaydırıcı)

Kaydırıcının çekiciliğini gerçekten korurken, yana doğru gezinmeye izin vermek istedik. Bu nedenle, iki navigasyon modelinin en iyi unsurlarını birleştiren bir hibrit çözüm geliştirdik. Bu arada, üzerinde anlaştığımız çözüm de buydu.

Hibrit profesyoneller:

• Yan tarama mümkündür.
• Animasyon kaygan.
• Hiyerarşi açıktır.

Hibrit eksileri:

• Bazı başlangıç ​​öğrenme gerektirir.
• Göz önünde bulundurulması gereken birçok hareketli parça ile geliştirilmesi karmaşıktır.
• Bazı performans sorunları var.

Belirtildiği gibi, kullanıcı, navigasyon ağacında yukarı ve aşağı gezinebilmeli, her zaman nereden geldiklerinin ve navigasyonun onları nereye götüreceğinin farkında olmalıdır. Ancak, bu sadece temel etkileşim - kullanılabilir bir navigasyon sistemi geliştirmek için birkaç ek sorunu ele almamız gerekti.

Sekiz Ayırt Edici Bağlantı Türü

Tasarımda farklı olan mevcut ve ata navigasyon öğelerinin yanı sıra (şu anda, neyse ki, iyi kurulmuş bir uygulamadır), kullanıcının nerede olduklarını ve ne keşfettiklerini anlamasına yardımcı olarak navigasyonu ve genel kullanılabilirliği daha da geliştirdik. Kullanıcının mevcut sayfayı ve ebeveynlerini ve ayrıca ilgili çocuk ilişkilerini anlamasına yardımcı olmak yeterli olmaktan çok uzaktı. Diğer önemli eylemler gerekliydi:

• doğrudan ana sayfaya gidebilmek;
• orijinal URL'de kalırken hem ebeveyn hem de çocuk seviyelerini önizleyebilme;
• navigasyonu keşfederken mevcut tarama konumlarını hızlı bir şekilde anlayın.
• sayfadaki mevcut konumlarını hızlı bir şekilde anlama.

Not: Geçerli sayfa konumunun kullanıcı için her zaman net olmasını sağlamak için içerik haritaları kullandık. Düzeyleri tamamen atlamaktan kaçınmak istediğimiz için, içerik haritalarındaki ve gezinmedeki bilgilerin, sözde düzeylerde (yani gerçek bir sayfası olmayan düzeylerde) bile bire bir eşleşmesi gerekiyordu.

Yukarıdaki kullanıcı gereksinimleri, kullanıcının mevcut sayfadan ayrılmak zorunda kalmadan ağaçta yukarı ve aşağı hareket etmesine izin verecek ek yardımcı bağlantılarla birlikte, anlamsal olarak farklı beş tür gezinme öğesiyle sonuçlandı. Bu kadar çok hareketli parçanın getirdiği karmaşıklığı ve karşılıklı bağımlılığı hayal edebilirsiniz.

Animasyon Ayrıntıları

Navigasyondaki tüm öğeler CSS kullanılarak canlandırılır ve her bir animasyonun iki farklı bölümü vardır:

• yatay animasyonlu seviyeler,
• dikey animasyonlu sarmalayıcılar.

İlk olarak, kaydırıcıdaki farklı ağaç seviyeleri, ana sarmalayıcının sınıfı değiştirilerek değiştirilir. Örneğin, kapalı gezinme sarmalayıcısı .depth-0 sınıfına sahiptir. Bir üst düzey öğe genişletildiğinde, sınıf .depth-1 olarak değişir. Bu üst düzey öğenin içinden ikinci düzey bir öğe seçildiğinde, sınıf .depth-2 olarak değişir ve bu böyle devam eder. Bu, bir kaydırıcıdaki en üst sıradaki liste olan tek bir öğeye uygulanan oldukça basit bir CSS kuralları kümesiyle sonuçlanır:

 .depth-1 .l-0.nav-open > ol { left: 0; } .depth-2 .l-0.nav-open > ol { left: -100%; } .depth-3 .l-0.nav-open > ol { left: -200%; }

Yukarıdaki örnekte, .l-0 sıfır seviyeli bir liste öğesine karşılık gelir ve akordeon open olarak ayarlandığında .nav-open open . Bu, open bir akordeon liste öğesindeki doğrudan bir alt öğenin sıralı listesinin kesinlikle negatif-sol konuma dengelendiği anlamına gelir.

İkinci olarak, her seviyenin değişken sayıda liste öğesi içerdiği düşünüldüğünde, herhangi iki bitişik seviye arasındaki geçiş düzgün olmalıdır.

Bunu başarmak için, yatay animasyonun sorunsuz çalışması için her zaman yeterli dikey alan olduğundan emin olduk. Yükseklik, ekrana girmek üzere olan elemanın dikey ofseti alınarak anında hesaplanır ve uygulanır. Bu, toplam dört olası senaryoyu hesaba katmamız gerektiği anlamına gelir, ancak gerçekte yalnızca, her biri biraz farklı yürütme sırasına sahip iki tanesini çözmemiz gerekir:

• Kısa liste öğesinden daha uzun bir liste öğesine . Yatay ve dikey animasyon aynı anda başlar.
• Uzun liste öğesinden daha kısa bir liste öğesine . Navigasyon yatay olarak kaymayı bıraktıktan sonra dikey animasyon başlar.

Her iki animasyon da aynı anda başlatılır, ancak ikinci animasyon, tam olarak ilk animasyonun süresi olan 300 milisaniyelik bir gecikmeden sonra başlatılır (CSS'de transition-duration özelliği kullanılarak belirtilir). Bunun nedeni, "perdenin arkasında" kaybolmadan önce birden çok katman üst üste bindiğinde, daha az yetenekli cihazlarda yetersiz animasyon performansıdır. Basitleştirilmiş kod şöyle görünür:

 if (newHeight < oldHeight) { heightTimeout = 300; } else { heightTimeout = 0; } setTimeout(function() { $('.l-0.nav-open').css('height', newHeight); }, heightTimeout);

Diğer İyileştirmeler

Halihazırda karmaşık bir dizi bağımlılıkla karşı karşıya olduğumuz için, navigasyonu test ettiğimizde iyileştirme için yer olduğunu fark ettik.

Birincisi, web yazı tipleri bazen sayfanın geri kalanından biraz daha geç yüklendiğinden, gezinmedeki bir satırda olması gereken bazı metin dizeleri, web yazı tipi tam olarak yüklenmeden önce ikinci bir satıra genişleyecektir. Örneğin, "Haberler, Medya ve Kaynaklar" üst düzey bölüm bağlantısı, geri dönüş yazı tipinde oluşturulduğunda iki satıra düşer.

Her şeyin gerçekten kompakt olması gerektiğinden (kayan animasyon için mutlak konumlandırma kullanmamız gerektiğinden), tek çözüm, web yazı tipi yüklendikten sonra etkilenen öğenin yüksekliğini sıfırlamaktı. Bu, Bram Stein tarafından Adobe Typekit ve Google Fonts için geliştirilen Web Font Loader kullanılarak yapıldı.

 WebFont.load({ custom: { families: ['FONT_NAME_1', 'FONT_NAME_2'] }, active: function() { // recalculate things here }, timeout: 5000 });

Not: 5 saniyelik bir zaman aşımını nasıl kullandığımızı fark ettiniz mi? Testlerimizde, bunun temel "iyi 2G" (saniyede 450 KB) bağlantımızda çalışmasını sağlayan en iyi nokta olduğunu gördük!

İkinci olarak, ilk yükleme performansını iyileştirmek için navigasyon düğümlerini koşullu olarak yüklemeye karar verdiğimiz için (bir sonraki bölümde bununla ilgili daha fazla bilgi), bir gecikme olması durumunda kullanıcının kaç navigasyon öğesinin mevcut olduğunun farkında olmasını istedik. gezinme ağacının bir dalını yüklerken. Bunu, bir metin dizisine benzeyen bir yer tutucu arka plan resmini tekrarlayarak yaptık.

Son olarak, navigasyon dalını talep etmeden önce DOM'daki yer tutucu kodunu JavaScript ile ekledik. Bu, DOM'yi olabildiğince temiz tutar.

 element.append('<ol class="nav-loading"><li class="nav-placeholder"></li></ol>'); $.get('NAVIGATION_BRANCH_URL', function(data){ // replace the loader with the branch element.find('ol').replaceWith(data); });

Verim

Hatırlarsanız, projedeki temel hedeflerimizden biri web sitesinin rakip web sitelerinden en az %20 daha iyi performans göstermesiydi. Sadece bu hedefe ulaşmakla kalmadık, bunu yaparken de SGS'nin toplam sayfa ağırlığını ve yükleme sürelerini önemli ölçüde azaltmasına yardımcı olduk. Aşağıdaki öncesi ve sonrası istatistiklerine bir göz atın:

12.000 Bağlantının 3 MB HTML'ye Eşit Olduğunu Biliyor muydunuz?

Bu doğru! Prototipimizde tam gezinme ağacını ilk kez oluşturduğumuzda, 3 MB çıplak HTML olarak gerçekleşti. Üst bilgi yok, alt bilgi yok ve içerik yok - yalnızca 12.000 ayrı bağlantıdan oluşan gezinme ağacı.

Yeniden tasarımdan önce, her sayfa temel gezinme ağacını içeriyordu ve her sektör sayfası ayrıca ayrı bir modül olarak uygulanan sektöre özel bir gezinme ağacını içeriyordu. Bununla birlikte, masaüstü için optimize edilmiş tasarım, çekirdek veya sektöre özel gezinmeyi yalnızca küçük görünüm pencerelerinde kullanmayı değil, aynı zamanda bakımını da zorlaştırdı. Bu nedenle, yeniden tasarımın ana hedeflerinden biri, ağacı tek ve bakımı kolay bir modülde birleştirmekti.

Performansı Artırmak için Seçenekleri Keşfetmek

Navigasyonun üç etkileşimli versiyonunun her birini kapsamlı bir şekilde test etmek ve performanslarını değerlendirmek için esnek bir test ortamı şarttı. Bu, değişiklikleri hızlı bir şekilde yapmamızı ve aynı zamanda birbirleriyle kolayca karşılaştırabilmemiz için eşzamanlı sürümleri korumamızı sağlar.

Navigasyon ağacının tamamının boyutu düşünüldüğünde (yedi seviye derinliğe ve 12.000 gezilebilir bağlantıya kadar), hem navigasyon ağacının bölümlerini hem de tam ağacın kendisini test edebilmek önemliydi. SGS'nin şirket içi geliştiricileri, tam gezinme ağacını içerik yönetim sistemlerinden bir CSV dosyası olarak dışa aktarabildiler; bu, ihtiyacımız olan şeye bağlı olarak, ağacın tamamını veya bir kısmını çıkarmak için kolayca yapılandırılabilir bir PHP işlevi oluşturmamıza olanak sağladı. test etmek.

PHP işlevimiz, yukarıda bahsedilen bağlantı işaretlemesi ve sınıf adları tek bir yerde kolayca değiştirilebildiğinden, gezinme ağacının yapısının HTML bakımını da basitleştirdi. Kodu tekrarlamak zorunda kalmamak için sunucu taraflı bir dil kullanmak kulağa bariz gelebilir, ancak bu tür bir ortamı oluşturmak sadece hoş bir ek değildi, aynı zamanda kritik bir görevdi, çünkü çevik deney ve test için ön koşuldu.

Koşullu Yükleme Bağlantıları

İlk yükleme performansını iyileştirmek için navigasyon düğümlerini koşullu olarak yüklememiz gerektiğinden bahsetmiştik. O zaman yanıtlanması gereken soru şuydu: Gezinti ağacının ne kadarı başlangıçta ve ne kadarı daha sonra ve ne zaman yüklenmelidir? Farklı gezinme ağacı dallarının ağırlıklarını ve boyutlarını test ettikten ve karşılaştırdıktan ve mevcut canlı web sitesinde kullanıcı davranışını inceledikten sonra, birkaç ilginç sonuç ortaya çıktı.

İlk olarak, yalnızca bir endüstri türüyle ilgilenen ziyaretçiler, diğer endüstrileri nadiren ziyaret etti. Seçtikleri endüstri kategorisine göz attıktan sonra, her ziyaretçi genellikle sadece birkaç diğer sayfayı keşfetmeye devam ederdi.

İkinci olarak (ve başlangıçta düşündüğümüz gibi), sektöre özgü branşlar, performans ek yükünün çoğuna neden oldu. Endüstri dallarını tamamen kaldırdığımızda, HTML 70 KB'ye düşürüldü, bu da 3 MB'den çok daha iyi! Yine de bu, 14 endüstri dalının her birinin 300 ile 500 KB arasında olduğu anlamına geliyordu. Her bir hizmet dalını daha fazla parçalara ayırdığımızda, sonraki her bir düzeyin ortalama olarak yaklaşık 24 KB ağırlığında olacağını gördük.

Sınıf adlarını optimize ederek ve JavaScript aracılığıyla DOM düğümleri ekleyerek HTML'nin daha da azaltılabileceğinin farkında olsak da (birazdan daha fazlası), yine de tek bir HTTP isteği başlatmanın en iyisi olup olmadığını belirlememiz gerekiyordu. 500 KB veya her düzeyde yaklaşık 24 KB'lık bir HTTP isteği başlatmak için. Başlangıçta, kullanıcı gezinme ağacında her ilerlediğinde 24 KB'lik bir istek göndermenin daha faydalı olacağı görülüyordu. Ancak bu, ağ gecikmesinin genellikle web sitesi performansı için en büyük darboğazlardan biri olduğu düşünüldüğünde, ideal olmaktan uzak olan ağ üzerinden birden fazla HTTP isteği gönderilmesine neden olurdu. Ayrıca, kullanıcının bir endüstri bağlantısının üzerine gelerek niyetini göstermesi dışında, herhangi bir endüstri dalının yüklenmesini tahmin etmek de mantıklı değildi.

Navigasyonun karmaşıklığı ve bağlantıların miktarı nedeniyle, aşağıdaki düzenleme açık ara en iyi uzlaşmayı sunar:

• HTML'de varsayılan olarak ilk üç düzeyi yükleyin.
• Amaç gösterildiğinde, mouseover üzerine gelme olayı kullanılarak algılandığında endüstri navigasyonunu JavaScript ile yükleyin.
• Ardışık sayfa yüklemelerinde yüklemeyi hızlandırmak için yüklenen dalları önbelleğe alın.

Daha derin sayfaların mantığı biraz farklıydı çünkü gezinmenin JavaScript etkinleştirilmeden erişilebilir olması gerekiyor. Bu nedenle, bir kullanıcı (hatta bir arama motoru botu) derin bir sayfaya girerse aşağıdakiler olur:

1. İlk üç seviyeyi ve mevcut sayfanın ata dalını ve sayfa kardeşlerini HTML olarak işleyin, böylece kullanıcının ebeveyn, ata ve kardeş sayfalarına kolayca erişmesine izin verirken, aynı mantıkla web sitesinin diğer bölümlerine de erişebilir.
2. Geçerli dalı JavaScript ile yükleyin ve başlangıçta yüklenen geçerli sayfanın ata dalını değiştirin.

HTML'yi optimize etme

HTML'nizi gerçekten optimize etmek istiyorsanız, gerekli olmayan tüm öğelerin CSS ve JavaScript'e yüklenmesi gerekir. Sıralı liste, liste öğeleri ve ilgili bağlantıları dışındaki her şeyi titizlikle budadık. Gerekli olmayan tüm bağlantılar (yani gezinme yardımcıları) da HTML'den kaldırıldı ve JavaScript kullanılarak DOM'ye yeniden eklendi (çünkü bunlar JavaScript olmadan zaten etkisizdirler). Bu zorunlu olmayan bağlantılar, kullanıcının birkaç şey yapmasını sağlar:

• bir sonraki seviyeyi açın (dahili olarak bunlara “genişleticiler” adını verdik);
• bir seviye yukarı çıkın (bu "destekçiler" adını verdik - hayal gücü eksikliğini gösteriyoruz).

Ortaya çıkan DOM hala çok büyük olsa da, navigasyon yardımcılarının artık ağ üzerinden ayrı ayrı aktarılmasına gerek yoktu.

Son olarak, üstlendiğimiz son optimizasyon parçası, sınıfların sayısını azaltmanın yanı sıra sınıf adlarının uzunluğunu kısaltmaktı; örneğin, .very-long-class-name .vlcn oldu. İkincisi en büyük kazanımları sağlasa da, bu tür bir optimizasyonun gerekçelendirilmesi zordur, çünkü genellikle HTML dosyasının boyutunu önemli ölçüde kırpmaz ve daha da önemlisi, kodun netliğini azaltır, böylece muhtemelen bakımı daha zor hale getirir. Bununla birlikte, 12.000 liste öğesinin her birinden tek bir bayt bile kırpmak, onu değerli bir alıştırma ve kabul edilebilir bir takas haline getirdi.

Sonuç? Büyük bir 40 KB ya da daha fazla ilk HTML (sıkıştırıldığında ve ağ üzerinden aktarıldığında 8 ila 9 KB) ve her endüstri için 200 ila 300 KB HTML (sıkıştırıldığında ve aktarıldığında 15 ila 25 KB).

Sonuç: Marjinal Kazançlar Önemlidir

Spor dünyasından bir benzetme kullanmayı seviyoruz: Her küçük şeyi %1 oranında iyileştirmek performansı önemli ölçüde artırır. Bu, SGS projesinde yaptıklarımız ve karmaşık navigasyonu için geçerlidir. Daha ince ayrıntılara odaklanarak, her ayrıntıyı biraz daha geliştirerek, navigasyonun karmaşıklığını önemli ölçüde azalttık ve yükleme sürelerini iyileştirdik, aynı zamanda navigasyonu kullanıcılar için çekici ve ilgi çekici hale getirdik. Bir kabus olabilecek ve kırılması zor bir somun, teknik ve etkileşimli olarak ilgili bir çözüme dönüştü, daha fazla iyileştirmeye uyum sağlayacak kadar esnek.

Hepsinden önemlisi, sürekli prototip oluşturma, seçenekleri araştırma ve en iyi çözümleri iyileştirme tasarım sürecinin son derece etkili olduğu kanıtlandı - o kadar ki, şirket içi ekibin diğer ürünleri geliştirirken aynı temel ilkeleri uygulaması için güçlü bir durum sağladı. organizasyonda, ekibin yeni navigasyon sistemini iyileştirmeye ve optimize etmeye devam etmesine yardımcı olacağından bahsetmiyorum bile. Hiçbir web projesi tam anlamıyla tamamlanmış değildir; yapılacaklar listesinde her zaman birkaç şey daha vardır. Kullanıcılar için en iyi deneyimi test etmeye, iyileştirmeye ve sunmaya devam ettiğimiz sürece bu gayet iyi.