Lighthouse Skoru Nasıl Yorumlanır?

Lighthouse için başlangıç ölçümünü netleştirin

Aynı sayfa farklı cihazlarda farklı sonuç üretir.

Mobil tarafta düşük işlem gücü ve ağ dalgalanması masaüstünde görünmeyen gecikmeleri büyütür. Tek sayı üzerinden acele karar vermek yerine dağılıma bakın. Teknik ekipte netleşmesi gereken alan: ölçüm varyansını kabul etmek ve ona göre hareket etmektir.

• Gerçek kullanıcı verisi: CrUX raporunda 75. yüzdelik dilimi izleyin, ortalamaya değil.
• Laboratuvar testi: Lighthouse'u aynı ağ profiliyle 5 kez çalıştırın, medyan değeri alın.
• Cihaz kırılımı: Düşük-orta-yüksek performanslı cihazlarda ayrı ayrı test edin.
• Zaman karşılaştırması: Değişiklik öncesi ve sonrası aynı saatte, aynı koşullarda ölçün.

Lighthouse darboğazını katman katman ayırın

Fırsatları önceliklendirirken render blocking çözümü ve lazy loading uygulama rehberi birlikte okunursa metrikler daha doğru bağlama oturur.

Performans sorunu geneldir, çözüm spesifik olmalı.

Gerçek kullanıcı verisinde açıkça görülen fark: aynı sayfanın farklı cihaz ve ağ profillerinde farklı sonuç üretmesi. Dağılıma bakın, tek sayıya değil. Mobil tarafta düşük işlem gücü ve ağ dalgalanması masaüstünde görünmeyen gecikmeleri büyütür.

• Ağır medya: 1MB üzeri görseller LCP'yi 2-3 saniye geciktirir, WebP + lazy loading ile 400ms'ye düşer.
• Bloklayan kaynak: Render-blocking CSS/JS sayısını 3'ün altına indirin, critical CSS inline yapın.
• Ana iş parçacığı yükü: Long Task sayısı 10'un üzerindeyse script execution süresini profilleyin.
• Sunucu gecikmesi: TTFB 600ms üzerindeyse CDN veya sunucu tarafı cache devreye alın.

Yalnızca raporda daha iyi görünen bir skor üretmek yetmez.

Lighthouse tarafında öncelik sırası kurun

Her iyileştirme eşit değildir.

İyileştirme kalitesini belirleyen adım: etki büyüklüğü ile uygulama maliyetini karşılaştırmak. Aynı sayfanın farklı cihaz ve ağ profillerinde farklı sonuç üretmesi normal, dağılıma bakın. Mobil tarafta düşük işlem gücü ve ağ dalgalanması masaüstünde görünmeyen gecikmeleri büyütür.

• Etki büyüklüğü: LCP'de 500ms kazanım mı, yoksa TBT'de 50ms kazanım mı? Kullanıcı hangisini hisseder?
• Uygulama maliyeti: 2 saatlik görsel optimizasyonu mu, yoksa 2 haftalık altyapı değişikliğini mi tercih edersiniz?
• Risk seviyesi: Değişiklik kritik yolda mı? Geri alma planı var mı? A/B test yapılabilir mi?
• Geri dönüş süresi: Sorun çıkarsa 5 dakikada mı, yoksa 2 saatte mi geri alabilirsiniz?

Lighthouse değişikliklerini küçük yayınlarla doğrulayın

Büyük değişiklikler büyük risk taşır.

Hız çalışmasını sürdürülebilir yapan yaklaşım: küçük adımlar, sık ölçüm, hızlı geri alma. Aynı sayfanın farklı cihaz ve ağ profillerinde farklı sonuç üretmesi normal, dağılıma bakın. Mobil tarafta düşük işlem gücü ve ağ dalgalanması masaüstünde görünmeyen gecikmeleri büyütür.

Önce gözlemi kayıt altına alın: ölçüm tarihi, cihaz tipi, sayfa türü ve metrik sonucu birlikte tutulduğunda hangi adımın gerçekten fayda sağladığı açık biçimde görünür.

• Aşamalı yayın: %5 trafikte test edin, sorun yoksa %25'e çıkarın, ardından %100'e yükseltin.
• Önce test sonra canlı: Staging ortamında 3 farklı cihaz profilinde test edin, sonuçları kaydedin.
• Regresyon kontrolü: Her yayın sonrası 24 saat içinde metrik dağılımını kontrol edin.
• Geri alma planı: Feature flag kullanın, sorun çıkarsa 5 dakikada geri alın.

Lighthouse verisini yanlış okumayın

Skor yorumunu güçlendirmek için TTFB kök neden analizi ve sayfa hızının iş etkisi aynı raporda değerlendirilmelidir.

Metrik okuma hatası iyileştirme hatasına yol açar.

Pratikte en çok atlanan nokta: aynı sayfanın farklı cihaz ve ağ profillerinde farklı sonuç üretmesi. Dağılıma bakın, tek sayıya değil. Mobil tarafta düşük işlem gücü ve ağ dalgalanması masaüstünde görünmeyen gecikmeleri büyütür.

Ölçüm tarihi, cihaz tipi, sayfa türü ve metrik sonucu birlikte tutulduğunda hangi adımın gerçekten fayda sağladığı açık biçimde görünür.

• Tek ölçüm yanılgısı: Lighthouse'u 1 kez çalıştırıp karar vermeyin, 5 kez çalıştırıp medyan alın.
• Aşırı ortalama kullanımı: Ortalama yerine 75. yüzdelik dilimi izleyin, çünkü kullanıcıların %25'i daha kötü deneyim yaşıyor.
• Coğrafya farkı: Avrupa'dan hızlı olan sayfa Asya'dan yavaş olabilir, CDN dağılımını kontrol edin.
• Cihaz sınıfı etkisi: Flagship telefonda 90 puan alan sayfa orta segment telefonda 40 puan alabilir.

Raporda daha iyi görünen bir skor üretmek yetmez.

Lighthouse için sürdürülebilir kontrol rutini kurun

Tek seferlik iyileştirme yetmez.

Teknik ekipte netleşmesi gereken alan: performans borcu sürekli birikir, düzenli temizlik gerekir. Aynı sayfanın farklı cihaz ve ağ profillerinde farklı sonuç üretmesi normal, dağılıma bakın. Mobil tarafta düşük işlem gücü ve ağ dalgalanması masaüstünde görünmeyen gecikmeleri büyütür.

Önce gözlemi kayıt altına alın: ölçüm tarihi, cihaz tipi, sayfa türü ve metrik sonucu birlikte tutulduğunda hangi adımın gerçekten fayda sağladığı açık biçimde görünür.

• Haftalık denetim: Her Pazartesi sabahı CrUX raporunu kontrol edin, 75. yüzdelik dilimde 200ms üzeri artış varsa alarm verin.
• Yayın öncesi kontrol: CI/CD pipeline'a Lighthouse entegre edin, LCP 2.5s üzerindeyse deploy'u engelleyin.
• Otomatik alarm: Slack'e günlük metrik raporu gönderin, eşik aşımlarını vurgulayın.
• Dokümantasyon disiplini: Her iyileştirmeyi tarih, metrik, değişiklik ve sonuçla birlikte kaydedin.

Vaka Notu: Yüksek puan ama zayıf deneyim

Bir içerik projesi raporda iyi puan gördüğü için performans tarafını kapatmıştı.

Kullanıcı geri bildirimlerinde etkileşim gecikmesi artıyordu. Sonraki incelemede toplam puan yerine metrik bazlı okuma yapıldı ve ana iş parçacığı yoğunluğu tespit edildi. Ekip görünmeyen sorunu doğru katmanda ele alabildi.

Raporun farklı saatlerde tekrar edilmesi dalgalanma profilini ortaya çıkardı. Yanlış pozitif sonuçlar ayıklandıktan sonra iki yüksek etkili adım seçildi: script yürütme yükünün azaltılması ve kaynak sırasının düzenlenmesi.

Puan artışı sınırlı kaldı ama kullanıcı tarafındaki akıcılık net biçimde yükseldi.