Teknik Test Araçları: Skora Değil Ölçüme Bakmak
Teknik test araçlarının ortak bir kusuru var: hepsi tek bir sayı üretmeye çalışıyor. O sayı çoğu zaman sitenin nasıl çalıştığını değil, aracın o an neyi ölçebildiğini anlatır. Araçlar yine de gerekli. Sonuçlarını okurken neyin ölçüldüğünü bilmek yeter.
PageSpeed skoru bir ölçüm değil, bir simülasyon
Google PageSpeed Insights aynı ekranda iki ayrı şey gösterir. Üstteki renkli skor laboratuvar tarafından gelir: kısıtlanmış bir işlemci ve taklit edilen bir mobil bağlantı üzerinde yapılan tek bir yükleme. Aynı sayfayı arka arkaya üç kez ölçün, üç farklı skor alırsınız. Sapma birkaç puanla kalmaz, sunucunun o anki yüküne ve ölçüm makinesinin sırasına göre onlu rakamlara çıkabilir.
Sayfanın alt tarafındaki Chrome Kullanıcı Deneyimi Raporu bölümü ise başka bir kaynaktan beslenir: son 28 günde sayfayı gerçekten açmış kullanıcıların tarayıcılarından toplanan veriler. Yavaş telefonlar, kötü şebekeler, eklenti yüklü tarayıcılar hepsi orada. Trafiği az olan sayfalarda bu bölüm boş gelir, çünkü anlamlı bir örneklem birikmemiştir.
Bir sitenin hızlı olup olmadığına laboratuvar skoruna bakarak karar vermem. Saha verisi yoksa elimde ölçüm değil tahmin var. Skorun asıl işi tanı koymak: hangi kaynağın render'ı bloke ettiğini, hangi görselin gereğinden büyük geldiğini gösterir. Bu liste tek yüklemede bile güvenilirdir, çünkü orada tahmin değil dosya boyutu vardır.
W3C doğrulaması hâlâ işe yarıyor, sanılan sebeple değil
Doğrulayıcıdan çıkan hata sayısının arama sıralamasıyla bir ilişkisi yok. Tarayıcılar bozuk HTML'i onarmak üzere tasarlandı, hata kurtarma davranışı standardın kendisinde tanımlı; kapatılmamış bir <li> yüzünden hiçbir sayfa görüntülenemez hale gelmiyor.
İşe yarayan kısım şu: doğrulayıcı, tarayıcının sessizce düzelttiği yerleri yüksek sesle söyler. Ve o düzeltme her zaman sizin beklediğiniz gibi olmaz. Yanlış yerde kapanan bir etiket DOM ağacını kaydırır, kaydırınca da CSS seçicileriniz ve querySelectorAll çağrılarınız bambaşka bir düğüm kümesine denk gelir. Tekrarlanan id değerleri de aynı sınıfa girer: sayfa açılır, ama getElementById ilkini döndürüp geri kalanını yok sayar ve ekran okuyucunun etiket eşlemesi bozulur. Hata listesini sıralama kaygısıyla değil, bu tür sorunları avlamak için tarayın.
Kırık link taramasının görünmeyen maliyeti
Link denetleyicileri iki tür yanlış üretir. Birincisi yanlış alarm: pek çok site tarayıcı olmayan istemcilere 403 döner, güvenlik katmanları otomatik istekleri baştan keser. Rapordaki kırmızı satırların önemli bir bölümü tarayıcıda açtığınızda gayet çalışır.
İkincisi daha sinsi. Denetleyici her sayfadaki her bağlantıyı ayrı ayrı isteğe çeviriyorsa, 500 sayfalık bir sitedeki tek bir altbilgi bağlantısı aynı adrese 500 istek demektir. Karşı taraf bunu tarama değil saldırı gibi görür ve IP'nizi kapatır. Aracın URL bazında tekilleştirme yapıp yapmadığına, istek hızını sınırlayıp sınırlamadığına bakın. Bu ayar yoksa araç kırık link bulmuyor, kırık link üretiyor.
Tarayıcı testinde parayı nereye harcamalı
Ücretli tarayıcı çiftlikleri onlarca kombinasyon vaat ediyor, çoğuna ihtiyacınız yok. Kendi analitiğinizi açıp trafiğin gerçekte hangi tarayıcı ve sürümlerden geldiğine bakmak listeyi genelde bir elin parmaklarına indirir.
Bir istisna var: iOS. Cihazdaki bütün tarayıcılar aynı motoru, WebKit'i kullanır. iOS'taki Chrome, masaüstündeki Chrome değildir; arayüzü Chrome, motoru Safari'dir. Masaüstü Chrome'da sorunsuz çalışan bir sayfanın iPhone'da bozulması bu yüzden sık görülür ve bunu ancak gerçek WebKit üzerinde test ederek yakalarsınız.
Testleri ne zaman çalıştırmalı
Elle test etmek unutulur. Hız ve doğrulama kontrollerini dağıtım hattına bağlayın, her yayında kendiliğinden koşsun; eşiği geçince derleme kırılsın. Kırık link taraması ise sürekli koşmaya değmez, ayda bir yeterlidir, çünkü bulduğu şey sizin kodunuzdaki bir gerileme değil dış dünyadaki bir değişimdir.
Bir de rapor arşivi tutun. Tek bir ölçümün gürültüsü yüksek, ama aynı sayfanın altı aylık eğrisi neyin gerçekten bozulduğunu tereddütsüz gösterir.
Kaynaklar