Web Sitesi Kullanılabilirliği: Ölçülebilir Hız ve Gezinme Kararları
Kullanılabilirlik tartışması çoğu yerde “site hızlı olsun, menü anlaşılır olsun” cümlesinde takılıp kalıyor. Oysa ikisi de ölçülebilir: hız için gerçek ziyaretçilerden gelen alan verisi, gezinme için görev tamamlama ve site içi arama kayıtları. Ölçmeye başladığınız anda hangi iyileştirmenin karşılığı olduğu, hangisinin sadece rapor süslediği de ortaya çıkar.
Hızı ortalamayla değil, p75 ile okuyun
Core Web Vitals üç şeye bakar: LCP sayfanın en büyük içerik öğesinin ne zaman göründüğünü, INP bir etkileşimden sonra arayüzün ne kadar geç cevap verdiğini, CLS de yerleşimin yükleme sırasında ne kadar kaydığını ölçer. “İyi” eşikleri sırasıyla 2,5 saniye, 200 milisaniye ve 0,1. INP, Mart 2024'te FID'in yerini aldı; eski dokümanlara bakıp FID kovalıyorsanız artık ölçülmeyen bir şeyi optimize ediyorsunuz.
Asıl atlanan nokta şu: bu eşikler ortalamaya değil, ziyaretçilerinizin 75. yüzdelik dilimine uygulanır. Yani skoru belirleyen, en yavaş çeyrek. Ortalama yükleme süresi 1,2 saniyeye inmiş olabilir ve p75 hâlâ 4 saniyede durabilir. Bu ikisi çelişmez, birlikte olur: hızlı cihazlar ortalamayı aşağı çeker, eski Android'ler ve zayıf mobil bağlantı p75'i yukarıda tutar. Dolayısıyla masaüstünüzde ölçüp iyileştirdiğiniz şeylerin çoğu skoru oynatmaz.
Ölçüm kaynağını da ayırın. Lighthouse laboratuvar verisidir: tek cihaz, tek bağlantı profili, tekrarlanabilir ama gerçek değil. Chrome User Experience Report ise sahadan, gerçek kullanıcılardan gelir. Değişikliğin işe yarayıp yaramadığını laboratuvarda hızlı görürsünüz, gerçekten yarayıp yaramadığını sahada 28 gün sonra.
Sırayla neye bakılır
LCP yavaşsa önce hangi öğenin LCP olduğunu bulun. Genelde kapak görseli ya da ilk başlık blokudur. Sonra o öğenin keşif zincirini çıkarın: tarayıcı onu HTML'i okur okumaz mı görüyor, yoksa bir CSS dosyasının arkasındaki arka plan görseli olduğu için stil indirilene kadar haberi olmuyor mu? Arkadan gelen sıra sunucu yanıt süresi, render engelleyen CSS ve JavaScript, en sonda da yazı tipi yükleme davranışı.
Görselleri tek tek elle sıkıştırmakla uğraşma; dönüşümü yayın adımına bırak, farklı ekran boyutları için srcset ver. Ve her görsele width ile height yaz: yer kaymasının büyük bölümü boyutu bilinmeyen görsellerden gelir, iki nitelik yazmak üçüncü parti bir araçtan daha çok iş görür.
Navigasyonda derinlik ve genişlik takası
“Kapsamlı ve hiyerarşik bir menü kurun” tavsiyesi eksik. Menüye eklediğiniz her yeni kategorinin maliyeti sadece onu arayan kişiye binmez, menüye bakan herkese biner; tarama süresi seçenek sayısıyla birlikte artar. Derin menü ise tersini yapar, her adımdaki seçeneği azaltır ama tıklama sayısını çoğaltır ve kullanıcıyı yanlış dala girip geri dönme riskiyle baş başa bırakır.
Pratik denge: üst düzeyde bir ekranda taranabilecek kadar başlık tutun, üç seviyeden aşağı inmeyin. Dördüncü seviyeye ihtiyaç duyduğunuz an, sorun menüde değil kategori şemasındadır.
Menüyü büyütmeden bulunabilirliği artıran şeyler de var ve ucuzdurlar: bulunulan konumu gösteren aktif durum işareti, uzun yollarda breadcrumb, ziyaret edilmiş bağlantının rengini ezmemek. Menünüzü klavyeyle baştan sona gezin, odak halkası her adımda görünüyor mu diye bakın. Fareyle açılan ama klavyeyle açılmayan bir alt menü, o dalın altındaki her sayfayı erişilemez yapar.
Büyüdükçe bozulan menü değil, etiketleme
Dinamik menülerin kendini otomatik güncellemesi kulağa çözüm gibi gelir. Değildir. Etiket kalitesi denetlenmediğinde menü büyüdükçe anlamını yitirir; “Diğer”, “Genel” ve “Kaynaklar” başlıkları yavaşça çöp kutusuna dönüşür ve bir süre sonra içeriğin nereye konacağına kimse karar veremez.
Bunun ölçüsü elinizin altında: site içi aramada sıfır sonuç dönen sorgular ve sonuç dönüp de hiçbir bağlantısı tıklanmayan sorgular. İlk liste eksik içeriği gösterir, ikincisi yanlış etiketlemeyi. Haftada bir bakılacak kadar kısa bir listedir ve kart sıralama çalıştırmadan da size şemanın nerede çatladığını söyler.
Yeni bölüm eklemek ucuz, geri almak pahalı. Kaldırdığınız her kategori arkasında kırık bağlantılar, dış sitelerden gelen ölü trafik ve yönlendirme yükü bırakır. Bu yüzden büyümeye hazırlık dediğimiz şey esnek bir menü bileşeni değil, yeni içeriğin nereye gireceğine karar veren yazılı bir kuraldır.