Site geneli ortalama yerine yolculuklarla başlayın
Gecikmenin açık bir müşteri veya operasyonel maliyeti olan üç ila beş yolculuğu listeleyin: bir kampanya sayfasına ilk iniş, ürün bulma, bir lead formu gönderme, oturum açma veya bir destek talebini tamamlama gibi. Her biri için başlangıcı, faydalı çıktıyı, ana cihaz sınıfını ve iyi çalışması gereken sayfayı veya etkileşimi yazın.
Her yolculuğa kendi bütçe satırını verin. Bir pano genel bir makaleden daha fazla kod taşıyabilir, ancak filtreleme eyleminin bir yanıt verme hedefi gerekir. Medya ağırlıklı bir ürün sayfası daha büyük görseller kabul edebilir, ancak ana görünen görsel için bir sınır olmalı. Bu, kritik bir yolun origin-genel ortalamada kaybolmasını önler.
Ziyaretçinin görebileceği veya yapabileceği şeyi adlandırın; örneğin teklifi okumak, bir sonuç görmek veya form onayı almak.
Önbellekleme varlık maliyetini önemli ölçüde değiştirebilir; bu yüzden bütçenin ilk ziyaret, tekrar ziyaret veya her ikisini kapsayıp kapsamadığını kaydedin.
Çıktılar ve kontrol edilebilir girdiler seçin
Hem çıktı metriklerini hem de giriş sınırlarını kullanın. Google, en büyük içerikli boyama olarak Largest Contentful Paint (LCP) yükleme performansını; Interaction to Next Paint olarak INP etkileşim yanıt verebilirliğini; ve Cumulative Layout Shift (CLS) görsel kararlılığı tanımlar. Önerilen iyi eşikler ayrı ayrı mobil ve masaüstü için 75. yüzdelikte LCP ≤ 2.5 saniye, INP ≤ 200 milisaniye ve CLS ≤ 0.1'dir.
Bir sebebi erken ortaya çıkaran sınırlar ekleyin: başlangıç JavaScript'i, ana içeristen önce gereken görseller, rota için toplam transfer, üçüncü taraf istekleri ve bilinen maliyetli bir widget. Sıkıştırılmış transfer boyutlarını tutarlı şekilde izleyin. Time to First Byte gibi tanılayıcılar yavaş yüklemeyi araştırmaya yardımcı olabilir, fakat tek başına müşteri çıktısı değildir.
Yolculuk ana içeriğin görünür olmasına bağlıysa LCP kullanın.
Arama, filtreleme, menüler ve ödeme sırasında alan INP kullanın; alan verisi yokken yalnızca laboratuvar proxy'si kullanın.
Sahiplerin bir ihlalin ardından hangi değişikliğin gerektiğini bilmesi için başlangıç rotasını ve en büyük katkı yapanları sınırlandırın.
Temeli baz alarak sayıları belirleyin
Her yolculuk için bir temel (baseline) yakalayın. PageSpeed Insights'ta gerçek Chrome-kullanıcı deneyimlerini toplayan Chrome User Experience Report (CrUX) alan verilerini Lighthouse laboratuvar verilerinden ayırın; alan verisi kullanıcılara ulaşan deneyimi kontrol ederken, laboratuvar testleri sürüm öncesi değişikliği tekrarlanabilir kılar.
En az mobil ve masaüstüye göre segmentleyin ve mümkünse kritik şablon veya URL bazında da ayırın. PageSpeed Insights URL verisi yoksa origin verisine geri dönebilir; bazı sayfaların CrUX verisi olmayabilir. Bu durumu bir laboratuvar temeli (lab baseline) olarak etiketleyin ve önemli yolculuklar için gerçek-kullanıcı ölçümü ekleyin. Her temel ile test URL'si, cihaz ve ağ profili, önbellek durumu, tarih ve araç sürümünü saklayın.
Temel deneyimi planlı bir iyileştirmeyle geliştirecek bir hedef seçin, sonra bunu temsilci koşullarda test edin. Normal sürümleri engelleyen bir bütçe aşılır; bugünkü deneyimin üzerinde olan bir bütçe ise kimseyi korumaz.
75. yüzdelik, gözlemlenen deneyimlerin %75'inin altında veya eşit olduğu değerdir; ortalama değildir.
Bütçeyi bir sürüm kuralı yapın
Bütçeyi kodun veya sürüm kontrol listesi yanında versiyonlanmış, incelenebilir bir yerde tutun. Her satırın yolculuğu, metriği, test profili veya popülasyonu, uyarı eşiği, hata eşiği, sahibi, ölçüm yöntemi ve istisna yolu olması gerekir. MDN uyarı ve hata seviyelerini önerir: uyarı proaktif planlama için, hata ise fark edilir negatif etkiye sahip üst bir sınırdır.
Güvenilir kontrolleri otomatikleştirin. Bir paketleyici (bundler) aşırı büyük bir varlığı veya başlangıç giriş noktasını reddedebilir; webpack maksimum varlık ve giriş-noktası sınırlarını ve üretim hata ipuçlarını destekler. Pull request veya sürüm adaylarında etkilenen yolculuk için tekrarlanabilir laboratuvar testleri çalıştırın. Sürüm engelleyici bir yapı kapısı olarak yerine, sürüm sonrası doğrulama ve önceliklendirme için alan metriklerini tutun; bunlar güvenilmez bir build gate değildir.
Bir limit başarısız olduğunda, bir varlığı küçültün, önemsiz kodu erteleyin, deneyimi değiştirin, sürümü bölün veya bir istisnayı onaylayın. Geçmek için eşiği gizlice yükseltmeyin.
Sürüm öncesi ürün ve teknik sahibi, müşteri etkisi, son kullanma tarihi ve düzeltme görevi kaydedin.
Korunan bir yolculukta çoğaltılabilir hata eşiğini engelleyin; uyarı eşiklerini bildirip araştırın.
Yayın sonrası doğrulayın ve düzeltin
Sayfa ağırlığı tam deneyimi tahmin etmez. İstek sırası, render-engelleyen işler, cihaz yeteneği, ağ koşulları, önbellekleme ve üçüncü taraflar da önemlidir. Girdi sınırlarını büyümeyi yakalamak için tutun ve yolun kullanılabilir olup olmadığını test etmek için çıktı ölçümlerini kullanın. W3C Resource Timing arabirimi, daha derin teşhis için kaynak zamanlamalarını ve transfer, kodlanmış ve çözülmüş boyutları açığa çıkarır. Çapraz-origin zamanlama ayrıntısı timing permissions ile kısıtlanabilir; bu yüzden eksik bir waterfall üçüncü taraf maliyeti olmadığına delil sayılmaz.
Önemli bir şablon, platform, pazarlama etiketi veya trafik değişikliğinden sonra alan sonuçlarını gözden geçirin. LCP kötüleşirse, sunucu yanıtını, LCP kaynağını ve render-engelleyen işleri inceleyin. INP kötüleşirse, gerçek etkileşimleri inceleyin; Lighthouse INP ölçemez çünkü kullanıcı girdisi yoktur, ancak Total Blocking Time laboratuvar proxy'si olarak kullanılabilir. SIU’nun proaktif optimizasyon iş akışını kullanarak bir ihlali triage edin, kritik yolu stabilize edin ve düzeltmeyi aynı ölçüm bağlamında doğrulayın.
Süresi dolmuş istisnalar geçici performans borcunun kalıcı hale geldiğini hızlıca ortaya çıkarır.