Kaydırma sırasındaki düzen kayması: bir kör nokta.
Klasik düzen kayması ölçümü sayfa yükleme penceresine bakar; kullanıcı kaydırmaya başladıktan sonra oluşan kaymalar o pencerede görünmez.
Bu sayfa bir teori değil, bu sitede ölçülerek bulunmuş bir kusurun kaydı. Ve kusurun kendisinden çok, nasıl bulunduğu öğretici — çünkü hiçbir genel denetim aracı onu göstermiyordu.
Durum şuydu: sayfa yüklenirken ölçülen düzen kayması sıfıra çok yakındı ve her araç yeşil veriyordu. Ama kullanıcı kaydırmaya başladığında, sabitlenmiş bir bölüm bırakılırken gözle görülür bir kayma oluşuyordu. İki gerçek aynı anda doğruydu: metrik iyiydi ve deneyim kötüydü.
Neden görünmüyor
Denetim araçları sayfayı açar, yüklenmesini bekler ve o pencerede biriken kaymayı raporlar. Kaydırma yapmazlar — çünkü kaydırma bir kullanıcı davranışıdır ve simüle edilmesi standart bir adım değildir. Dolayısıyla kaydırmayla tetiklenen hiçbir kayma o ölçüme girmez.
Saha verisinde bu kaymalar görünür çünkü gerçek kullanıcılar kaydırır. Ama saha verisi toplu ve gecikmelidir; bir kaymanın hangi bölümden geldiğini söylemez. Yani sorun saha verisinde bir sayı olarak belirir, laboratuvar ölçümünde hiç belirmez, ve arada teşhis boşluğu kalır.
Boşluk bir araç eksikliği değil, bir soru eksikliğidir. Araç «yüklenirken kayıyor mu» diye soruyordu ve doğru cevabı veriyordu. «Kaydırırken kayıyor mu» sorusunu kimse sormuyordu.
Metrik iyiydi ve deneyim kötüydü; ikisi de doğruydu çünkü metrik o soruyu sormuyordu.
Sabitlenmiş bölümler
Kaymanın kaynağı, kaydırmayla senkronize çalışan sabitleme davranışıydı. Bir bölüm ekranda sabit tutulur, kaydırma devam ederken içerik değişir ve bölüm bırakıldığında sayfa akışına geri döner. O geri dönüş anında, bölümün kapladığı yer yeniden hesaplanır ve altındaki içerik kayar.
Bu, hareket kütüphanelerinin klasik bir yan etkisidir ve neredeyse her zaman aynı sebepten doğar: sabitleme, öğeyi belge akışından çıkarıp geri koyarak yapılır. Alternatif yöntem — öğeyi akışta bırakıp yalnız dönüşüm özelliğiyle hareket ettirmek — düzeni hiç etkilemez ve kayma üretmez.
Düzeltme bu yönde yapıldı ve iki ayrı nöbetçiyle kilitlendi. Birincisi doğrudan sorunu ölçüyor: sabitleme ve bırakma anındaki kayma 0,01'in altında kalmalı. İkincisi daha genel: kaydırma boyunca Google'ın oturum penceresi mantığıyla hesaplanan en kötü pencere 0,08'in altında kalmalı — Google'ın iyi eşiği olan 0,1'in altında bilinçli bir pay bırakarak.
Nasıl ölçülür
Bu ölçümü kurmak özel bir araç gerektirmiyor; tarayıcının kendi düzen kayması gözlemcisi kullanılabiliyor. Fark, ölçümün ne zaman yapıldığında: sayfa yükleme penceresinde değil, kaydırma sırasında.
- Sayfayı aç ve yüklenmesini bekle — başlangıç kaymasını ayrı ölç.
- Gözlemciyi sıfırla — bundan sonrası kaydırma kayması sayılacak.
- Programatik olarak kaydır — gerçek kullanıcı hızına yakın adımlarla, sayfanın tamamı boyunca.
- Kaymaları pencerelere böl — Google'ın oturum penceresi mantığıyla; en kötü pencereyi al.
- Eşiğe bağla — resmî eşiğin altında bir hedef koy ki gerileme erken görünsün.
- Her dağıtımda koştur — bir kez ölçüp geçmek, bir sonraki hareket eklemesinde bozulur.
Dördüncü madde kritik: pencere mantığının Google'ın kendi hesabıyla aynı olması, testin gerçekten aynı şeyi ölçtüğünü garanti ediyor. Toplam kaymayı ölçen bir test, uzun sayfalarda gereksiz yere kırmızı verir ve bir süre sonra görmezden gelinir.
Genel ders
Bu vakanın asıl öğrettiği şey sabitleme tekniği değil, denetim yöntemi. Yeşil bir rapor, sorulan soruların cevabıdır — sorulmayan sorular hakkında hiçbir şey söylemez. Ve bir aracın hangi soruyu sorduğunu bilmek, denetimi yapanın sorumluluğudur.
Aynı örüntü erişilebilirlik tarafında da yaşandı bu sitede: bir kontrast ölçütü hiçbir araç tarafından sınanmıyordu ve o boşlukta gerçek bir kusur yaşıyordu. İki vaka farklı alanlarda ama aynı dersi veriyor.
Pratik sonuç: her ölçüm aracının kapsamını bir kez okuyun, kapsamadığı ölçütleri listeleyin, ve o listeyi kendi testlerinize çevirin. Genel araçların kapsamadığı boşluk, projeye özgü nöbetçilerle kapanır — başka türlü kapanmaz.
Benzer kör noktalar
Bu vakanın örüntüsü tek bir metrikle sınırlı değil ve aynı mantıkla başka kör noktalar da aranabilir. Ortak soru şu: bu metrik hangi PENCEREDE ölçülüyor ve o pencerenin dışında ne oluyor?
- Etkileşim tepkiselliği — ölçüm gerçek etkileşim gerektirir; hiç etkileşilmeyen bir testte görünmez.
- Uzun görevler — sayfa yüklendikten sonra çalışan periyodik işler, yükleme penceresinde yok.
- Bellek sızıntısı — uzun oturumlarda birikir; tek sayfa açılışında hiç görünmez.
- Kaydırma performansı — kare düşmeleri yalnız kaydırırken oluşur.
- Gömülü içerik — kullanıcı etkileşimiyle yüklenen kaynaklar ilk ölçümde yok.
Beş maddenin ortak yanı, hepsinin gerçek kullanımda oluşup standart bir açılış testinde hiç görünmemesi. Bu, otomatik denetimin sınırını bir kez daha gösteriyor: araç bir senaryoyu ölçüyor ve o senaryo dışındaki her şey hakkında sessiz kalıyor.
Bu sitede kaydırma sırasındaki kayma ve kare bütçesi ayrı testlerle ölçülüyor; ikisi de standart araçların kapsamadığı sorular. Kare bütçesi eşikleri saniyede altmış kare hedefinden türetilmiş: medyan 12 milisaniyenin, 95. yüzdelik 24 milisaniyenin altında.
Kapanışta bir yöntem önerisi: kendi sitenizde kör nokta aramanın en verimli yolu, gerçek kullanım senaryolarını yazmak ve her senaryoda hangi metriğin ölçüldüğünü sormaktır. Kullanıcı sayfayı açıyor, kaydırıyor, bir düğmeye basıyor, bir katman açıyor, geri dönüyor — her adımda hangi araç ne ölçüyor? Ölçülmeyen adımlar, kör noktaların listesidir ve o liste doğrudan yeni testlere dönüşür.
Pratik kontrol listesi
Bu sayfanın anlattıklarını bir denetim adımına çevirmek gerekirse, ölçüm kör noktalarını için bakılacaklar şunlar. Liste kısa tutuldu çünkü uzun listeler yürünmüyor; altı madde bir oturumda tamamlanabilir.
- Bu metrik hangi pencerede ölçülüyor?
- O pencerenin dışında ne oluyor — kaydırma, etkileşim, uzun oturum?
- Araç sayfayla etkileşiyor mu — etkileşmiyorsa etkileşim metrikleri eksik.
- Gerçek kullanım senaryosu yazıldı mı — her adımda hangi araç ne ölçüyor?
- Ölçülmeyen adımlar listelendi mi — o liste yeni testlerin planı.
- Bulunan her kusur bir teste bağlandı mı?
Altıncı madde bu sitenin çalışma biçiminin özeti: bir kusuru düzeltmek onu bir kez ortadan kaldırır, bir nöbetçi eklemek geri gelmesini engeller.