Lighthouse 100 aldık ama site yavaş: laboratuvar ile saha arasındaki fark
Laboratuvar ölçümü kontrollü bir ortamda tek bir yükleme yapar. Gerçek kullanıcılar öyle davranmaz. Saha verisiyle laboratuvar verisi çeliştiğinde ne yapıyoruz?
Bir müşterimizin yeni sitesi Lighthouse'da dört alanda da 100 alıyordu. Aynı hafta gelen kullanıcı geri bildirimlerinde en sık cümle şuydu: "Sayfa açılırken donuyor."
İkisi de doğruydu.
Laboratuvar ölçümü neyi ölçmez
Lighthouse, kontrollü bir ortamda, soğuk önbellekle, sabit bir ağ profilinde tek bir yükleme yapar. Bu, karşılaştırma için mükemmel bir zemindir. Ama gerçek kullanıcı deneyimini üç noktada temsil etmez:
- Cihaz çeşitliliği. Laboratuvar profili orta seviye bir cihazı taklit eder. Gerçek trafiğinizin bir kısmı çok daha yavaş cihazlardan gelir.
- Etkileşim zamanlaması. Kullanıcı sayfa yüklenmesini beklemez; yüklenirken tıklar. Lighthouse tıklamaz.
- Gezinti biçimi. İlk yükleme ile uygulama içi gezinti farklı maliyetlere sahiptir; laboratuvar yalnızca ilkini ölçer.
Bizim vakamızda sorun tam olarak ikinci maddeydi: INP (Interaction to Next Paint) laboratuvar ölçümünde hiç görünmüyordu.
Sahada neyi topluyoruz
Her projede, ilk sürümle birlikte gerçek kullanıcı ölçümü (RUM) devreye alıyoruz. Toplanan alan seti kasıtlı olarak küçük:
| Alan | Neden | | --- | --- | | LCP, CLS, INP, TTFB | Çekirdek metrikler | | Rota şablonu | Hangi sayfa türü sorunlu | | Cihaz sınıfı | Düşük/orta/yüksek | | Bağlantı türü | 4g, 3g, slow-2g | | Gezinti türü | İlk yükleme mi, istemci içi gezinti mi |
Kişisel veri toplamıyoruz; URL'ler şablona indirgeniyor (/blog/[slug]), böylece ölçüm anonim kalıyor.
Karar verirken ortalamaya değil 75. yüzdeliğe bakıyoruz. Ortalama, en kötü deneyimleri gizler.
Bulduğumuz üç sorun
1. Uzun görevler ilk tıklamayı yutuyordu.
Sayfa görsel olarak hazırdı ama ana iş parçacığı hâlâ hidrasyonla meşguldü. Kullanıcı tıklıyor, hiçbir şey olmuyor, tekrar tıklıyor.
Çözüm, işi bölmek değil, işi kaldırmaktı. Etkileşim gerektirmeyen bileşenleri sunucu bileşenine çevirdik; istemci paketindeki bileşen sayısı 34'ten 11'e düştü. INP 75. yüzdeliği 310 ms'den 140 ms'ye indi.
2. Yazı tipi geç geliyordu, ama CLS sıfırdı.
CLS sıfır olduğu için kimse bakmamıştı. Oysa metin, yazı tipi yüklenene kadar görünmüyordu (font-display: block davranışı). Kullanıcı boş bir alan görüyordu.
display: swap ve doğru bir yedek yazı tipi ölçeklemesiyle metin anında göründü; kayma da oluşmadı çünkü yedek fontun metrikleri hedef fonta yakın ayarlandı.
3. Üçüncü taraf betiği ilk boyamayı geciktiriyordu.
Analitik betiği <head> içinde senkron yükleniyordu. Laboratuvarda betik önbellekten geldiği için maliyeti görünmüyordu; sahada, yavaş bağlantılarda LCP'yi 900 ms geciktiriyordu.
next/script ile afterInteractive stratejisine geçirdik. Kaybettiğimiz tek şey, sayfayı hemen terk eden kullanıcıların ölçümüydü — kabul edilebilir bir takas.
Sonuç
Üç değişiklikten sonraki dört haftalık saha verisi:
- LCP (p75): 2,9 sn → 1,6 sn
- INP (p75): 310 ms → 140 ms
- CLS (p75): 0,02 → 0,01
Lighthouse skoru değişmedi. Zaten 100'dü.
Çıkarılan ders
Laboratuvar skoru bir gerileme testidir: "yeni sürüm eskisinden kötü mü?" sorusunu ucuza yanıtlar. Ama "kullanıcılarım ne yaşıyor?" sorusunu yanıtlamaz.
Her iki ölçümü de tutun. Çeliştiklerinde sahaya inanın.
- Core Web Vitals
- Performans
- RUM
- Next.js