Çoğu ekip aynı rutine girer: Lighthouse'u açar, puanı görür, kırmızı olanları düzeltmeye çalışır ve skoru izler. Hedefe dönüşen bu sayı, zamanla gerçek sorunun önüne geçer. Oysa Lighthouse puanı bir performans ölçütü değildir — birkaç metriğin, belirli ağırlıklarla hesaplanmış ortalamasıdır. 74'ten 82'ye çıkmak kullanıcının fark ettiği bir şey olmayabilir; 61'de takılı kalan bir sayfa ise gerçekte son derece hızlı hissettiriyor olabilir. Fark, neyin ağırlıklı olduğunda ve o ağırlıkların hangi koşulda ölçüldüğünde gizlidir.

Sorun puanın yanlış olması değil, yanlış okunmasıdır. Lighthouse belirli koşullarda çalışan bir lab aracıdır. Hesaplamasındaki ağırlıklar bazı metrikleri diğerlerinden çok daha belirleyici kılar. Sunduğu bulgular iki farklı kategoriye ayrılır — birini öne alıp diğerini görmezden gelmek sık yapılan bir hatadır. Aracı doğru konumlandırmak, sonuçlarını doğru önceliklendirmenin ön koşuludur.

Lab skoru ile saha verisi arasındaki uçurum

Lighthouse sabit bir test ortamında çalışır: simüle edilmiş 4G ağ profili (yaklaşık 150 ms RTT, 1,6 Mbps indirme hızı) ve CPU performansını yapay olarak kısıtlayan bir throttle mekanizması. Bu koşullar, güçlü bir ofis bağlantısında değil, orta segment bir cihazla mobil ağda gezinen bir kullanıcıyı temsil etmeye çalışır. Ama simülasyon, gerçekliğin kendisi değildir.

Chrome UX Report (CrUX) ve Google Search Console'daki Core Web Vitals verileri, gerçek kullanıcılardan toplanan saha ölçümüdür. Pratikte lab ve saha değerleri çoğu zaman ciddi biçimde ayrışır. Bir sayfanın Lighthouse LCP'si 1,8 saniye gösterirken saha LCP'si 4,2 saniyede kalabilir — çünkü gerçek kullanıcılar farklı cihazlardan, farklı ağlardan ve farklı coğrafyalardan geliyor. Bazı projelerde bu fark iki kattan fazla olabilir.

Düzeltme önceliği belirlenirken önce saha verisine bakılmalıdır. Lab'da 3 saniye görünen bir LCP, sahada zaten 1,5 saniyeyse öncelikli konu bu değildir. Saha verisi yoksa ya da yetersizse Lighthouse sonuçları geçerli bir proxy olarak kullanılabilir — ama bu durumda bulguların gerçek etkisini abartmamak gerekir.

Opportunity ile Diagnostic ayrımı neden önemlidir

Lighthouse bulguları iki gruba ayrılır: Opportunity (fırsat) ve Diagnostic (tanı). Bu ayrımı gözden kaçırmak önceliklendirmeyi bütünüyle bozar.

Opportunity'ler doğrudan yükleme süresi üzerindeki tahmini kazancı gösterir. "Görselleri sıkıştır: ~1,4 s tasarruf" ya da "render-engelleyen kaynakları kaldır: ~0,9 s tasarruf" gibi. Bu tahminler kesin değildir — sayfanın gerçek koşullarına göre değişir — ama hangi müdahalenin belgelenmiş bir etkisi olduğunu net biçimde ortaya koyar. PageSpeed Insights arayüzü de bu ayrımı benzer şekilde sunar; iki araç aynı altyapıyı paylaşır.

Diagnostic'ler ise iyi pratikle ilgili sinyaldir. "DOM boyutu 1.800 düğümü aşıyor", "uzun ana thread görevleri tespit edildi", "JavaScript yürütme süresi yüksek" gibi bulgular önemlidir; ama Lighthouse bunlara belirli bir süre tasarrufu atfetmez. Diagnostic, neye bakılacağını söyler; Opportunity, neyin önce çözüleceğini. Düzeltme listesi yapılırken Opportunity'leri tahmini süre kazancına göre sıralamak, Diagnostic'leri ise ayrı bir gözden geçirme başlığında tutmak çok daha verimli bir çalışma ritmi üretir.

Ağırlıklı metrik hesabı puanı nasıl çarpıtır

Lighthouse v10 ile birlikte performans puanı beş metriğin ağırlıklı ortalaması üzerinden hesaplanmaktadır: TBT %30, LCP %25, CLS %25, FCP %10, Speed Index %10. TTI bu versiyonla birlikte hesaplamadan çıkarıldı.

Bu dağılım birkaç şeyi açığa çıkarır. TBT ve LCP birlikte toplam puanın %55'ini belirler. CLS üçüncü büyük katkıyı sağlar. FCP ve Speed Index toplamda yalnızca %20 ağırlığındadır. Pratik sonuç şudur: FCP'yi 400 ms iyileştirmek puanda yaklaşık 2-3 puan fark yaratırken, aynı çabayla elde edilecek bir TBT düşüşü puanı çok daha fazla yukarı taşır. LCP'yi 0,5 s kısaltmak da benzer biçimde etkili olur.

Bu mekanizma bazı optimizasyon kararlarını çarpıtır. Skoru artırmak amacıyla TBT'ye odaklanmak mantıklı görünür — TBT gerçekten önemli bir metriktir, INP ile doğrudan ilişkilidir. Ama TBT'yi 50 ms düşürmek için yapılan agresif bir kod bölme çalışması, LCP'yi 0,5 s kötüleştirebilir. Net puan değişimi pozitif görünse bile kullanıcı deneyimi açısından denge bozulmuş olabilir. Ağırlıkları bilmek, "puanı yükseltmek" ile "performansı iyileştirmek" arasındaki farkı somutlaştırır. Her zaman aynı yönü göstermezler.

Hangi Lighthouse uyarısı gerçekten önceliklidir

Bir Lighthouse raporunda onlarca bulgu görünebilir. Önceliği belirlemek için üç soruyu yanıtlamak çoğu durumda yeterlidir.

İlk soru: Saha verisinde de bu sorun var mı? Lab'da görünen ama sahada izi olmayan bir uyarı düşük önceliklidir. İkinci soru: Opportunity mı, Diagnostic mı? Tahmini süre kazancı küçükse bulgu önemsiz olmayabilir, ama başka şeyler daha acil olabilir. Üçüncü soru: Etkilenen metrik ağırlıklı mı? Render engelleyen kaynaklar FCP'yi etkiler — %10 ağırlıklı. Ana thread'i bloke eden JavaScript TBT'yi etkiler — %30 ağırlıklı. Aynı efor harcandığında hangisinden başlanacağı bu soru ile netleşir.

Pratikte şu tablo ortaya çıkar: "Kullanılmayan JavaScript" uyarısı neredeyse her sayfada görünür ve çoğu zaman büyük tasarruf vaat eder, ama kaynak üçüncü parti bir betikse müdahale alanı sınırlı olabilir. "Görseller uygun boyutta değil" uyarısı ise genellikle doğrudan LCP'ye dokunur ve düzeltmesi görece kolaydır. İkisi aynı raporda yan yana görünüyorsa ikincisi daha önce ele alınmalıdır — puan artışı daha küçük olsa bile gerçek kullanıcı etkisi daha büyüktür.

Puan yerine metrik odaklı çalışmak

Lighthouse'u açtığınızda ilk göze çarpan şey büyük puan dairesidir. Ama asıl bilgi onun altındadır: LCP, TBT ve CLS değerleri, renk kodlamasıyla birlikte.

Bu üç metriği referans noktası olarak almak, skora odaklanmaktan çoğu durumda daha verimli sonuç üretir. LCP 2,5 saniyenin altında mı? TBT 200 ms'nin altında mı? CLS 0,1'in altında mı? Bu eşikler Lighthouse'un "iyi" olarak renklendirdiği aralıklardır ve saha ölçümünde de aynı eşikler kullanılır. Metrikler bu hedeflerde kararlıysa puan 85'in altında kalsa bile kullanıcı deneyimi gerçek anlamda iyidir.

Tersine, puan 90'ın üzerinde ama LCP sahada tutarsızsa — yani bazı kullanıcılar için 3,5 saniyeyi aşıyorsa — bu tablo puanın iyi göründüğü ama işin bitmediğini ortaya koyar. TTFB yüksekse LCP'nin bu bölümünü düşürmek için sunucu tarafına bakmak gerekir; Lighthouse bunu Diagnostic olarak gösterir ama ağırlıklı bir metriği doğrudan etkiler. Metrik odaklı çalışmak aynı zamanda ekip içi tartışmayı da netleştirir: "Puanı kaç yaptık?" sorusu yerine "LCP'yi kaça çektik, saha verisi ne diyor?" sorusu somut bir hedef üretir.

Lighthouse güçlü bir araçtır — ama çıktısını doğru okumak, aracı açmaktan daha fazla iş gerektirir. Lab koşullarının sınırlarını, ağırlık dağılımının yarattığı puanlama dinamiklerini ve Opportunity ile Diagnostic arasındaki temel farkı anlamak, rapordan çıkarılacak önceliklendirmeyi kökten değiştirir.

Puan bir özet sinyaldir. Anlamlı sorular onun altında başlar: hangi metrik, ne kadar, saha verisinde de aynı mı? Bu soruları yanıtlamak bazen puanı yükseltmez — ama gerçek kullanıcı deneyimini iyileştirir. Ve nihayetinde ölçülmesi gereken de budur.