Lighthouse Skoru Nasıl Yorumlanır?

Önce ölçüm yöntemini ve varyansı anlayın

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ıya odaklanmak yerine dağılıma bakın. Ölçüm varyansını kabul etmeden yapılan her iyileştirme kararı eksik veriyle alınmış olur.

• 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.

Rapordaki fırsatları kaynağında sınıflandırın

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

Performans sorunları çoğunlukla tek katmandan kaynaklanmaz. Ağır medya, bloklayan kaynak, ana iş parçacığı yükü ve sunucu gecikmesi birbiriyle etkileşime girer. Biri için yapılan müdahale diğerini gün yüzüne çıkarabilir.

• 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.

Fırsat listesini etki büyüklüğüne göre sıralayın

Lighthouse'un Opportunities sekmesi fırsatları sıralar; ama öncelik kararını siz vermelisiniz.

Etki büyüklüğünü uygulama maliyetiyle karşılaştırmadan otomatik sıraya uymak çoğu zaman yanlış önceliğe yol açar. Bazı küçük değişiklikler 400ms kazandırırken bazı büyük refaktorlar yalnızca 30ms sağlar.

• 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?

Her müdahaleyi izole ederek doğrulayın

Birden fazla değişiklik aynı anda uygulandığında hangisinin işe yaradığı anlaşılamaz.

Küçük adımlar, sık ölçüm ve hızlı geri alma — bunların her biri tek başına değer taşır ama birlikte uygulandığında regresyonu erken yakalamak çok daha kolaylaşı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.

Skoru değil, metrik ilişkisini okuyun

TTFB değerini katmanlara ayırmak ve sayfa hızının iş üzerindeki etkisini bilmek Lighthouse çıktısını daha sağlam bağlama oturtur.

Metrik okuma hatası çoğunlukla iyileştirme hatasına dö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.

Lighthouse beş kategoriyi ayrı ayrı değerlendirir

Lighthouse raporu açıldığında üst kısımda beş farklı daire görünür: Performance, Accessibility, Best Practices, SEO ve PWA. Bu kategorilerin her biri bağımsız hesaplanır ve birbirinin puanını etkilemez. "Performans skoru düşük" diyenlerin büyük çoğunluğu yalnızca ilk daireye bakıyor; diğerleri de değerli bilgi içerir.

Performance kategorisi altı metrikten oluşur ve her birinin farklı ağırlığı vardır. FCP ile Speed Index düşük ağırlıklı olup skora az katkı sağlar. LCP ve TBT (Total Blocking Time) yüksek ağırlıklıdır; bu iki metrikte sorun varsa puan hızla düşer. CLS orta ağırlıklıdır. INP ise Lighthouse'un laboratuvar ortamında doğrudan ölçemediği bir metrik olduğundan raporda farklı biçimde temsil edilir.

Accessibility skoru HTML semantiği, renk kontrastı, klavye erişilebilirliği ve ARIA kullanımını denetler. Bu puan düşükse arama motorları sayfanızı daha zor anlar; aynı zamanda yardımcı teknoloji kullanan ziyaretçiler sayfada gezinmekte güçlük çeker. SEO kategorisi ise meta etiketler, canonical, robots.txt ve sayfa indekslenebilirliğini kontrol eder.

Laboratuvar verisi ile saha verisi neden farklı çıkar?

Lighthouse bir laboratuvar aracıdır. Sayfayı kontrollü bir ortamda, sabit ağ ve CPU ayarlarıyla yükler; her çalıştırmada aynı koşulları uygular. Bu kontrollü ortam tekrarlanabilirliği sağlar; ancak gerçek kullanıcı davranışını tam olarak yansıtmaz.

Saha verisi ise Chrome User Experience Report (CrUX) üzerinden toplanır. Gerçek kullanıcıların farklı cihazlarından, farklı ağ koşullarından ve farklı coğrafyalardan gelen ölçümlerin agregasyonudur. Bir kullanıcı 2G bağlantıyla, diğeri 5G ile aynı sayfayı açabilir; ikisi de saha verisine dahil olur.

Bu iki veri kaynağını birbirinden ayırmanın pratik önemi büyüktür. Lighthouse puanı iyiyken CrUX verisinde sorun çıkabilir; çünkü gerçek cihaz ve ağ dağılımı laboratuvar simülasyonundan farklıdır. Tersi de olabilir: bazı optimizasyonlar laboratuvarda ölçülemeyen ama sahada belirgin fark yaratan iyileştirmeler getirir. Doğru karar için her iki kaynağa da bakılması gerekir.

• Lighthouse (lab): Kök neden tespiti için güçlü; spesifik optimizasyon önerileri sunar, tekrarlanabilir test ortamı sağlar.
• CrUX (field): Gerçek kullanıcı deneyimini yansıtır; PageSpeed Insights ve Search Console üzerinden erişilebilir.
• WebPageTest: Farklı lokasyon ve ağ profillerinden test imkânı sunar; waterfall analizi için tercih edilir.
• Chrome DevTools: Anlık profil çıkarmak ve specific etkileşimleri kayıt altına almak için en pratik araçtır.

Opportunities ve Diagnostics bölümleri farklı şeyler söyler

Lighthouse raporu iki farklı öneri bölümü içerir ve bunları birbirine karıştırmak sık yapılan bir hatadır. Opportunities bölümü, uygulandığında yüklenme süresini doğrudan kısaltacak değişiklikler önerir ve her önerinin yanında tahmini kazanım miktarı gösterilir. Diagnostics bölümü ise performansı olumsuz etkileme potansiyeli olan sorunları listeler; ama bunların doğrudan ne kadar süre kazandıracağı belirtilmez.

Opportunities önceliklidir çünkü sayısal etki tahmini içerir. "Render-blocking kaynakları ortadan kaldırın" önerisi yanında "1.2 s kazanılabilir" yazıyorsa, bu bilgi öncelik kararında doğrudan kullanılabilir. Diagnostics önerileri ise uzun vadeli kod kalitesini ve sürdürülebilirliği hedefler; daha az acil ama göz ardı edilirse birikerek sorun oluşturur.

Passed Audits bölümü ise raporda en sık atlanan kısımdır. Burası neyin doğru yapıldığını listeler. Gerileme tespiti açısından değerlidir; daha önce geçen bir denetim artık geçmiyorsa, bu bir deployment değişikliğinin izini taşıyor olabilir.

Lighthouse'u nerede ve nasıl çalıştırmalısınız?

Lighthouse'a erişmenin birden fazla yolu vardır ve her yol farklı bir kullanım amacına hizmet eder. Chrome DevTools üzerinden çalıştırmak en hızlı yöntemdir; Incognito modda, tüm uzantılar devre dışıyken test edin, aksi hâlde uzantılar skoru ciddi biçimde düşürebilir.

PageSpeed Insights, aynı Lighthouse motorunu kullanır; ek olarak CrUX verisini de sayfanın üst kısmında gösterir. Hem laboratuvar hem de saha verisini tek ekranda görmek için en pratik seçenektir. Üstelik URL bazlı çalıştığından yerel ortam gereksinimi yoktur.

Lighthouse CLI, otomasyon ve CI/CD entegrasyonu için tercih edilir. Node.js üzerinden çalışır ve çıktıyı JSON formatında kaydeder. Bu sayede her deployment sonrasında otomatik test yapıp skoru önceki değerle karşılaştırmak mümkün olur. Skor belirli bir eşiğin altına düşerse deployment işlemi engellenebilir.

• DevTools (Incognito): Hızlı, pratik, anlık analiz için; uzantı kirliliğinden kaçınmak için Incognito modu kullanılmalı.
• PageSpeed Insights: Lab + field verisi birlikte; URL bazlı, ücretsiz, kurulum gerektirmez.
• Lighthouse CLI: CI/CD entegrasyonu, JSON çıktı, threshold kontrolü için otomasyon odaklı.
• WebPageTest + Lighthouse: Farklı lokasyon ve ağ profillerinde Lighthouse çalıştırmak için gelişmiş seçenek.

Tüm bu araçların ortak noktası şudur: test sonucu öneriyle biter ama karar sizindir. Araç hangi sorunun büyük olduğunu söyler; çözümün hangi sıraya alınacağını, hangi riskin kabul edileceğini ve hangi değişikliğin daha önemli bir hedefe hizmet ettiğini siz belirlersiniz.

Düzenli kontrol olmadan puan artışı geçicidir

Tek seferlik iyileştirme yetmez.

Performans borcu sessizce birikir. Yeni özellikler eklendikçe, üçüncü parti scriptler çoğaldıkça kontrol döngüsü olmayan ekipler gerilemeyi geç fark eder.

• 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.