Lab ölçümü, saha verisi ve gerçek bir telefon

Bir sayfa iyi puan alır ve yine de yavaş hissettirir. Başka bir sayfa kötü puan alır ve kimse ondan şikâyet etmemiştir. İkisi de normaldir, çünkü sentetik bir denetim, saha verisi ve elinizdeki telefon üç ayrı soruyu yanıtlayan üç ayrı araçtır; herhangi birini gerçeğin kendisi saymak da kimseye yaramayan işler üretir. İşe yarayan beceri, hangi araca uzanacağınızı ve her birinin neyi yanlış gösterdiğini bilmektir.

Üç araç, üç soru

Sentetik denetim sayfayı bir kez koşturur: simüle edilmiş bir cihazda, simüle edilmiş bir bağlantıda, boş bir cache'le ve genelde gerçek bir ziyaretin peşinden sürüklediği eklentiler, onay bantları ve tag'ler olmadan. Güçlü yanı tekrarlanabilir olmasıdır: değişiklikten önce ve sonra koşturursanız fark büyük ölçüde sizin değişikliğinizdir. Zayıf yanı, simüle ettiği cihazın kimsenin sahip olmadığı bir cihaz olması ve anlattığı çalışmanın hiçbir insanın başına gelmemiş olmasıdır.

Saha verisi gerçek oturumlardan gelir ve bir dağılım olarak raporlanır; ilgi de ortalamaya değil yavaş uca verilir, çünkü ortalama kötü zaman geçiren insanları saklar. Güçlü yanı doğru olmasıdır. Zayıf yanı hiçbir şeyi açıklamamasıdır: ziyaretçilerin dörtte birinin dört saniye beklediğini söyleyebilir, neyi beklediğini söyleyemez. Bir de gecikir, çünkü kayan bir pencerede toplanır; pazartesi çıktığınız değişiklik üç haftalık eski kodla seyrelir.

Gerçek bir bağlantıdaki gerçek bir telefon, hissi raporlayan tek araçtır. Takılan bir kaydırma, yarım saniye hiçbir şey yapmayan bir dokunuş, fontlar geldikten sonra zıplayan bir yerleşim, yazdığınız alanın üstünü kapatan bir klavye. Bunların hiçbiri diğer iki araçta temiz biçimde görünmez.

Üçünü birlikte kullanmanın bir sırası da var. Saha verisi hangi sayfanın sorunlu olduğunu söyler, denetim o sayfada neyin beklendiğini gösterir, telefon da yaptığınız değişikliğin gerçekten hissedilip hissedilmediğini doğrular. Sırayı tersine çevirdiğinizde, yani telefonunuzda fark ettiğiniz bir şeyden yola çıktığınızda, genelde kendi cihazınıza özgü bir sorunu bütün ziyaretçilerin sorunu sanırsınız.

Hangisi ne zaman yanıltır

• Denetim, ziyaretçileriniz simüle ettiği cihazda değilse yanıltır. Trafiğinizin çoğu hızlı bağlantıda ve sıcak cache'teyse, kısıtlanmış orta seviye bir telefondaki boş cache tipik durum değil en kötü durumdur; ona göre optimize etmek kimseye yaramayan bir işe mal olabilir.
• Denetim, çalışmalar arası oynaklık değişikliğinizden büyükse yanıltır. Tek bir çalışma bir örnektir ve tek bir örnek, kodunuzla hiç ilgisi olmayan sebeplerle birkaç puan oynayabilir.
• Saha verisi, trafiğiniz azsa yanıltır. Birkaç bin örneğin altında dağılımın yavaş ucu bir avuç oturumdur ve trendeki tek bir kişi onu oynatabilir.
• Saha verisi, tek bir sayfa ya da tek bir bölge baskınsa yanıltır. Aslında tek bir popüler sayfadan ibaret olan site geneli bir sayı, sitenin geri kalanı hakkında hiçbir şey söylemez; sonuç çıkarmadan önce kırılımlara bakın.
• Telefon, sizin telefonunuzsa yanıltır: kendi wifi'nizde, sıcak cache'le, az önce kurduğunuz ve nereye bakacağınızı bildiğiniz sayfayı açarken. Bu bileşim her şeyi iyi hissettirir.

Tekrarlayabileceğiniz bir yöntem

Beş adım; disiplin araçlarda değil, adımları sırayla yapmakta:

1. Tek bir metrik ve tek bir sayfa seçin. Skor değil metrik, en ilginç bulduğunuz sayfa değil en çok trafik alan sayfa.
2. Baseline alın. Birkaç çalışma, kaydedilmiş ve dağılımı görünür halde. Ölçümlerinizin ne kadar zıpladığını söyleyemiyorsanız, gerçek bir iyileşmeyi gürültüden ayıramazsınız.
3. Tek bir şeyi değiştirin.
4. Birebir aynı koşullarda yeniden ölçün. Aynı bağlantı profili, aynı cache durumu, aynı sayıda çalışma.
5. Sayıyı ve değişikliği tutup tutmadığınızı yazın. Kimsenin yazmadığı bir sayı üç ay sonra yeniden tartışılır.

Baseline için, tekrarlanan herhangi bir şey özenli tek bir çalışmadan iyidir. Kaba hali tek satır:

for i in $(seq 1 9); do
  curl -so /dev/null -w '%{time_starttransfer}\n' https://ornek.com/
done | sort -n | awk '{a[NR]=$1} END {printf "min %s medyan %s max %s\n", a[1], a[int((NR+1)/2)], a[NR]}'
# min 0.048 medyan 0.061 max 0.139

Bu yalnızca sunucu tarafını kapsar ama yanıtlanmaya değer ilk soruyu yanıtlar: gecikme yanıtı üretmekte mi, yoksa render etmekte mi? Medyan zaten altmış milisaniyeyse hiçbir front end çalışması işe yaramaz ve bakmanız gereken yer yavaş sorgudan doğru indekse tarafıdır.

Render tarafında ise sayıdan çok elementin kimliği işe yarar. Aşağıdaki kod, tarayıcının en büyük içerik boyaması saydığı elementi raporlar; bundan sonra ne yapacağınızı en çok değiştiren bilgi de budur:

new PerformanceObserver((list) => {
  const e = list.getEntries().at(-1);
  console.log(
    Math.round(e.startTime),
    e.element ? e.element.tagName : '(yok)',
    e.url || '',
  );
}).observe({ type: 'largest-contentful-paint', buffered: true });
// 1840 IMG https://ornek.com/a/hero.9f1c2a44.avif
// 2210 H1

Cevap bir görselse iş boyutlandırma ve formattır. Bir başlıksa iş genelde boyamayı bloklayan bir font ya da stylesheet'tir. Çalışmalar arasında değişiyorsa sayfada bir yarış durumu vardır ve onu çözene kadar ortalamanın anlamı yoktur.

Skor tuzağı

Bileşik skor, her biri eşikli bir eğriden geçirilen birkaç metriğin ağırlıklı toplamıdır. Bundan iki sonuç çıkar. Bir değişiklik, sırf bir eşiği geçtiği için, kimsenin hissetmediği halde skoru oynatabilir. Ve bir değişiklik, aynı bant içinde kaldığı için, her ziyaretçiye biraz fayda sağladığı halde skoru hiç oynatmayabilir.

Pratikteki etkisi şudur: skorun peşinden gitmek, yapmaya değer değişikliği değil yapması en ucuz olanı seçer. Ziyaretçinin gerçekten beklediği şey yerinde dururken bir sayıyı üç puan oynatmaya harcanan öğleden sonralar gördüm; aynı tuzağı öbür taraftan anlatan yazı da şu: giriş animasyonunuz en büyük boyamayı geciktiriyor.

Bundan kaçınmanın yolu, herhangi bir sayıya bakmadan önce değişikliği kullanıcı terimleriyle ifade etmektir. "Başlık, font gelmeden boyanıyor" kontrol edebileceğiniz bir iddiadır. "Skor 89'dan 92'ye çıktı" hiçbir şeye dair bir iddia değildir. Önce birinci türden cümleyi kurun, ölçümü de onu doğrulamak ya da çürütmek için kullanın.

Çalıştığını nasıl doğrularsınız

Maliyeti ve değeri artan sırayla üç kontrol:

# aynı komut, aynı koşullar, değişiklikten sonra
for i in $(seq 1 9); do
  curl -so /dev/null -w '%{time_starttransfer}\n' https://ornek.com/
done | sort -n | awk '{a[NR]=$1} END {printf "medyan %s aralık %s\n", a[int((NR+1)/2)], a[NR]-a[1]}'
# medyan 0.058 aralık 0.031

Sonra denetimi aynı sayıda tekrarlayın ve en iyi çalışmaları değil medyanları karşılaştırın. Ardından sayfayı orta seviye bir telefonda, mobil veriyle ve cache'i temizlenmiş halde açın ve sayıya değil sayfaya bakın. Üçü de aynı şeyi söylüyorsa değişiklik gerçektir. Denetim iyileşip telefon iyileşmediyse sayfayı değil ölçümü değiştirmişsinizdir.

Saha verisi yavaş onaydır. Sürüm tarihini grafiğe işaretleyin ve çizginin ertesi gün değil izleyen haftalar içinde oynamasını bekleyin, çünkü pencere hâlâ eski koddan gelen oturumlarla dolu.

Nelere dikkat etmeli

• Siteyi derleyen makinede ölçmek. Sıcak cache'li, ağı olmayan yerel bir sunucu, temsil gücü olmadığı garanti tek ortamdır.
• Aynı anda iki şey değiştirmek. İkisi birlikte çıkar ve sayı iyileşirse ikisi hakkında da hiçbir şey öğrenmemişsinizdir, üstelik biri durumu kötüleştiriyor olabilir.
• Kimsenin girmediği sayfayı optimize etmek. Başlamadan önce sayfaları trafiğe göre sıralayın ve sıkıcı sayfanın genelde önemli olan sayfa olduğunu kabul edin.
• Bir şey hızlandığı için değil yüklenmeyi bıraktığı için iyileşen metrik. Özelliğin hâlâ çalıştığını kontrol edin, özellikle iyileşme şüphe uyandıracak kadar büyükse.
• İçeriği farklı bir sayfa üzerinde koşan denetime güvenmek. Test ortamında üç kayıtlı bir liste sayfası, ziyaretçinin gördüğü üç yüz kayıtlı liste sayfası değildir ve fark sorunun tamamı olabilir; responsive images denetimi size aslında ne söylüyor yazısında da sık sık öyle olur.

Önce ölçmek kendini amorti eder, çünkü tahmin pahalıya mal olacak sıklıkta yanlış çıkar; titizlik merakının bununla bir ilgisi yok. Üzerinde çalıştığım her performans probleminin bariz bir sebebi vardı ve o sebep listenin ikinci ya da üçüncü sırasından çıktı; bunu bilmemin tek sebebi de birinin baseline'ı yazmış olması. Baseline'ı alın, tek bir şeyi değiştirin, aynı koşullarda ölçün ve sayıyı bir sonraki kişinin bulabileceği bir yerde bırakın. Araçların önemi, sıranın öneminin yanında çok küçük kalır.