Lighthouse Raporu Nasıl Okunur

Lighthouse raporunun en üstündeki renkli daire, performans işinde en çok yanlış anlaşılan sayıdır. Kimi "90 aldık, iş bitti" der, kimi 62'yi felaket sanıp haftalarca uğraşır. Oysa o skor tek başına bir hedef değil, altındaki beş metriğin ağırlıklı ortalamasıdır; ve o beş metriğin hangisinin skoru aşağı çektiğini bilmeden yapılan her müdahale kör atıştır.

Bu rehberde Lighthouse raporunu yukarıdan aşağıya okuyacağız: skorun matematiği, beş metriğin ağırlıkları, "Fırsatlar" ile "Tanılar" arasındaki kritik fark, aracın neyi ölçmediği ve raporu yanıltan tipik durumlar. Sonunda bir rapora baktığınızda hangi üç satırla ilgileneceğinizi ve gerisini neden görmezden gelebileceğinizi bileceksiniz.

Lighthouse Ne Ölçer, Ne Ölçmez#

Lighthouse, Chrome'un içine gömülü açık kaynaklı bir denetim aracıdır. Bir sayfayı kontrollü koşullarda yükler, ölçer ve beş kategoride rapor üretir: Performans, Erişilebilirlik, En İyi Uygulamalar, SEO ve (varsa) PWA. En önemli özelliği, ölçümü simüle edilmiş koşullarda yapmasıdır: mobil profilde yavaş bir mobil bağlantı ve işlemci hızını yaklaşık dörtte birine indiren bir kısıtlama uygular. Bu yüzden Lighthouse skoru, sizin fiber bağlantınızla gördüğünüz hızı değil, ortalama bir kullanıcının deneyimini temsil etmeye çalışır.

Lighthouse'un ölçmediği şey ise gerçek ziyaretçilerinizdir. Tek bir yükleme, tek bir cihaz, tek bir ağ profili. Kullanıcılarınızın yarısı masaüstünden ve hızlı bağlantıdan geliyorsa mobil skor sizi gereksiz yere korkutur; tam tersi durumda da yanlış bir güven verir. Bu ayrım o kadar önemlidir ki Google, sıralama sinyali olarak Lighthouse skorunu değil gerçek kullanıcı verisini kullanır. Laboratuvar ile saha verisi arasındaki farkı CrUX alan verisi ve lab verisi yazısında ayrıntılı ele aldım.

Bir de sık karıştırılan nokta var: PageSpeed Insights ile Lighthouse aynı şey değildir. PageSpeed Insights sayfanın üst kısmında CrUX'tan gelen gerçek kullanıcı verisini, alt kısmında ise Lighthouse'un laboratuvar ölçümünü gösterir. Üstteki bölüm sıralama açısından anlamlı olandır; alttaki bölüm ise size ne yapacağınızı söyleyendir.

Performans Skoru Nasıl Hesaplanır#

Performans skoru beş metriğin ağırlıklı ortalamasıdır. Lighthouse 10 ve sonrasında ağırlıklar şöyledir:

Bu tablodan çıkan ilk sonuç şu: skorunuz düşükse ilk bakacağınız yer TBT ve LCP'dir, çünkü ikisi birlikte skorun yüzde 55'ini oluşturur. FCP'yi 200 ms iyileştirmek skorda birkaç puan getirirken, TBT'yi 600 ms'den 200 ms'ye indirmek onlarca puan getirebilir.

Her metrik ham değerden puana çevrilirken logaritmik bir eğri kullanılır. Bunun pratik anlamı önemlidir: kötü bir değeri biraz iyileştirmek çok puan kazandırır, iyi bir değeri daha da iyileştirmek neredeyse hiç puan kazandırmaz. LCP'yi 6 saniyeden 4 saniyeye indirmek büyük sıçrama yaratır; 2,1 saniyeden 1,9 saniyeye indirmek ise skorda fark edilmez. Bu yüzden hedef "100 almak" değil, tüm metrikleri yeşil bölgeye taşımak olmalıdır.

Skor renkleri de sabittir: 0-49 kırmızı, 50-89 turuncu, 90-100 yeşil. 90 üzerine çıkmak çoğu içerik sitesinde mümkündür; ağır bir uygulama arayüzünde 75-85 bandı gayet sağlıklı bir sonuçtur.

Beş Metriği Tek Tek Okumak#

Raporun "Metrics" bölümünde beş değer yan yana durur. Her birinin size söylediği şey farklıdır:

• FCP yüksekse sorun sunucu cevabında (TTFB) ya da render engelleyen kaynaklardadır. Ayrıntı için FCP nasıl iyileştirilir yazısına bakın.
• LCP yüksek ama FCP iyiyse, sorun genellikle ana görselin geç keşfedilmesi veya çok büyük olmasıdır. LCP iyileştirme yazısı bu ayrımı ele alıyor.
• TBT yüksekse JavaScript yükü fazladır; bu, skorun en ağır kalemidir ve TBT rehberinde ayrıntılandırdım.
• CLS yüksekse boyutu belirtilmemiş görseller, sonradan enjekte edilen banner'lar ya da yazı tipi değişimi vardır. CLS düzen kayması yazısı çözümleri sıralıyor.
• Speed Index tek başına nadiren aksiyon üretir; genelde LCP ile birlikte hareket eder. LCP'yi düzeltince o da düzelir.

Raporun sağ üstündeki "View Original Trace" veya "View Treemap" bağlantıları çoğu kişinin atladığı iki hazinedir. Treemap, sayfaya yüklenen JavaScript'i dosya dosya boyutlandırarak gösterir ve hangi kütüphanenin ne kadar yer kapladığını bir bakışta ortaya koyar; TBT ile uğraşırken ilk açacağınız görünüm budur.

Fırsatlar ile Tanılar Arasındaki Fark#

Rapordaki en yaygın hata, "Opportunities" (Fırsatlar) listesini yukarıdan aşağıya bir yapılacaklar listesi sanmaktır. Bu bölümdeki her satırın yanında bir tahmini kazanç süresi yazar — örneğin "Kullanılmayan JavaScript'i kaldırın — 1,35 sn". Bu süre bir simülasyon tahminidir, garanti değildir. Aynı düzeltmeyi yapıp 1,35 saniye kazanamayabilirsiniz.

"Diagnostics" (Tanılar) bölümü ise tahmini kazanç vermez, sadece durumu bildirir: "Ana iş parçacığı çalışmasını en aza indirin", "Aşırı DOM boyutundan kaçının" gibi. Bu satırlar aksiyon üretmeyeceğiniz anlamına gelmez; tam tersine, TBT sorunlarının kökü genellikle burada durur.

Pratikte izlediğim öncelik sırası şudur:

1. Ağırlığı en yüksek metriği belirle (genelde TBT ya da LCP).
2. Sadece o metriği etkileyen fırsat/tanı satırlarını süz.
3. Her düzeltmeyi tek tek uygula ve arasında yeniden ölç.
4. Kazanç 100 ms'nin altındaysa bir sonrakine geç.

Bu sıra, "listedeki 14 uyarının hepsini kapatmaya çalışma" tuzağından kurtarır. Bazı uyarılar (üçüncü taraf çerezleri, belirli konsol hataları) sizin kontrolünüzde bile olmayabilir.

Lighthouse'u Doğru Çalıştırmak#

Tarayıcı eklentilerinin açık olduğu normal bir Chrome penceresinde alınan ölçüm güvenilir değildir; eklentiler ana iş parçacığına kod enjekte eder ve TBT'yi şişirir. Doğru yöntem gizli pencere kullanmak ya da doğrudan komut satırına geçmektir:

# Temiz bir profil ile mobil olcum
npx lighthouse https://firmaniz.com/ \
  --form-factor=mobile \
  --screenEmulation.mobile \
  --only-categories=performance \
  --chrome-flags="--headless --no-sandbox" \
  --output=html --output-path=./rapor.html

Tek bir ölçüme asla güvenmeyin. Lighthouse'un doğal değişkenliği yüzünden aynı sayfada arka arkaya alınan üç ölçüm arasında 8-10 puan fark görebilirsiniz. Sağlıklı yöntem birkaç kez ölçüp medyanı almaktır:

# Ust uste 5 olcum, sadece performans skorunu yazdir
for i in $(seq 1 5); do
  npx lighthouse https://firmaniz.com/ --only-categories=performance \
    --chrome-flags="--headless" --output=json --output-path=/tmp/lh-$i.json --quiet
  node -e "console.log(Math.round(require('/tmp/lh-$i.json').categories.performance.score*100))"
done

CI süreçlerine bağlamak isterseniz lighthouse-ci aracı eşik değer tanımlamanıza ve skor düştüğünde derlemeyi kırmanıza izin verir. Bu, performansın zamanla geri kaymasını önlemenin en etkili yoludur; çünkü performans bir kez yapılıp bitirilen bir iş değil, sürekli korunması gereken bir durumdur.

Performans Dışındaki Kategoriler#

Rapordaki diğer üç kategori, performans kadar konuşulmaz ama düşük maliyetli kazançlar barındırır.

Erişilebilirlik kategorisi renk kontrastı, form etiketleri, alt metinleri ve odak sırası gibi denetimleri içerir. Lighthouse burada yalnızca otomatik test edilebilen maddeleri kontrol eder; 100 almak sitenizin erişilebilir olduğu anlamına gelmez, ama 60 almak kesinlikle bir sorun olduğu anlamına gelir.

En İyi Uygulamalar kategorisi HTTPS kullanımı, konsol hataları, güvenlik açığı bilinen kütüphaneler ve doğru görsel en-boy oranı gibi maddeleri denetler. Buradaki "bilinen güvenlik açığı olan kütüphane" uyarısını ciddiye alın; genellikle uzun süredir güncellenmemiş bir eklentiye işaret eder.

SEO kategorisi ise yüzeyseldir: title, meta açıklama, robots.txt erişimi, kanonik etiket ve mobil uyumluluk gibi temel maddelere bakar. Buradan 100 almak sitenizin arama sonuçlarında iyi olacağını göstermez, sadece teknik engel olmadığını gösterir.

Raporu Saklamak ve Değişimi Takip Etmek#

Tek seferlik bir rapor size fotoğraf verir, ihtiyacınız olan ise filmdir. Bir düzeltmenin gerçekten işe yarayıp yaramadığını anlamanın tek yolu, öncesi ve sonrası ölçümleri aynı koşullarda alıp yan yana koymaktır. Lighthouse'un JSON çıktısı bunun için idealdir, çünkü sadece skoru değil her metriğin ham değerini de içerir.

Basit bir takip düzeni şöyle kurulabilir: her dağıtımdan sonra ölçüm alın, tarihli bir dosyaya yazın ve yalnızca ilgilendiğiniz beş değeri çekin.

# Tarihli rapor uret ve bes metrigi ozetle
TARIH=$(date +%F)
npx lighthouse https://firmaniz.com/ --only-categories=performance \
  --chrome-flags="--headless" --output=json \
  --output-path=./raporlar/lh-$TARIH.json --quiet

node -e "
const r = require('./raporlar/lh-$TARIH.json');
const a = r.audits;
console.log([
  'Skor: ' + Math.round(r.categories.performance.score * 100),
  'FCP: ' + a['first-contentful-paint'].displayValue,
  'LCP: ' + a['largest-contentful-paint'].displayValue,
  'TBT: ' + a['total-blocking-time'].displayValue,
  'CLS: ' + a['cumulative-layout-shift'].displayValue
].join(' | '));
"

Bu çıktıyı bir metin dosyasında biriktirdiğinizde, üç ay sonra "site neden yavaşladı" sorusuna dakikalar içinde cevap verirsiniz: hangi tarihte hangi metriğin sıçradığını görür, o tarihteki dağıtıma bakarsınız. Deneyimlerime göre performans kayıplarının büyük çoğunluğu tek bir büyük hatadan değil, aylar içinde eklenen küçük betiklerin birikmesinden kaynaklanır ve ancak böyle bir kayıtla fark edilir.

Skoru Yanıltan Durumlar ve Sık Yapılan Hatalar#

En yaygın hata, skoru farklı koşullarda karşılaştırmaktır. Mobil profilde alınan 58 ile masaüstü profilinde alınan 94 aynı sitenin skorudur; ikisini yan yana koyup "iyileşti" demek anlamsızdır. Karşılaştırma yapacaksanız aynı profil, aynı araç ve tercihen aynı saat dilimi kullanın.

İkinci hata, çerez banner'ını ve A/B testlerini hesaba katmamaktır. Lighthouse her yüklemede taze bir profil kullandığı için çerez onay kutusu her seferinde görünür ve çoğu zaman LCP öğesi olur. Gerçek kullanıcılarınızın çoğu bu kutuyu ilk ziyarette görüp bir daha görmez; yani laboratuvar skorunuz sistematik olarak daha kötü çıkar.

Üçüncü hata, oturum açılmış sayfaları ölçmektir. Lighthouse anonim bir ziyaretçi gibi davranır; üyelik gerektiren bir panel adresini ölçerseniz aslında giriş sayfasını ölçmüş olursunuz.

Dördüncü hata, skoru tek gerçek kabul edip waterfall'a hiç bakmamaktır. Lighthouse size "ne" olduğunu söyler, "neden" olduğunu değil. Sebebi görmek için isteklerin zaman çizelgesine bakmanız gerekir; yöntemi waterfall grafiği nasıl okunur yazısında anlattım. Farklı bir araçla ikinci bir görüş almak isterseniz GTmetrix ile WordPress hız testi yazısı da aynı ölçümü başka bir arayüzden ele alıyor.

Sıkça Sorulan Sorular#

Lighthouse skoru kaç olmalı#

Yeşil bölge 90 ve üzeridir ama bunu mutlak hedef saymayın. İçerik ağırlıklı bir sitede 90+ ulaşılabilir; e-ticaret ya da yoğun JavaScript kullanan bir arayüzde 75-85 bandı gerçekçi ve sağlıklıdır. Asıl hedef skorun kendisi değil, LCP, INP ve CLS'in gerçek kullanıcı verisinde yeşil olmasıdır.

Lighthouse skoru neden her seferinde değişiyor#

Çünkü ölçüm sırasında ağ gecikmesi, işlemci meşguliyeti ve üçüncü taraf sunucularının cevap süresi değişkendir. Aynı sayfada 8-10 puanlık dalgalanma normaldir. Bu yüzden tek ölçüme değil, birkaç ölçümün medyanına bakın ve karşılaştırmalarınızı hep aynı koşullarda yapın.

PageSpeed Insights ile Lighthouse arasındaki fark nedir#

PageSpeed Insights, Lighthouse'u bulutta çalıştırır ve buna ek olarak CrUX'tan gelen gerçek kullanıcı verisini de gösterir. Yani Lighthouse laboratuvar ölçümü verir, PageSpeed Insights hem laboratuvar hem saha verisi sunar. Sıralama açısından anlamlı olan, sayfanın üst kısmındaki saha verisidir.

Lighthouse skorunu Google sıralamada kullanıyor mu#

Hayır. Google sıralama sinyali olarak Lighthouse skorunu değil, CrUX üzerinden toplanan gerçek kullanıcı Core Web Vitals verisini kullanır. Lighthouse bir teşhis aracıdır; skorunuz 100 olsa bile saha verisi kötüyse sıralama açısından kazancınız olmaz.

Lighthouse'u kendi sunucumda çalıştırabilir miyim#

Evet. npx lighthouse komutu Node kurulu her makinede çalışır ve headless Chrome ile ölçüm yapar. Sunucuda çalıştırırken ölçümün sunucunuzun ağ konumundan yapıldığını unutmayın; kullanıcılarınız başka bir ülkedeyse sonuçlar iyimser çıkar. Sürekli izleme için lighthouse-ci ile eşik değer tanımlamak daha sağlıklıdır.

Rapordaki uyarıların hepsini kapatmam gerekir mi#

Hayır ve bu genellikle zaman kaybıdır. Uyarıların bir kısmı sizin kontrolünüz dışındaki üçüncü taraf kaynaklardan gelir, bir kısmının kazancı ise ölçülemeyecek kadar küçüktür. Skorun yüzde 55'ini oluşturan TBT ve LCP'yi etkileyen satırlara odaklanın; 100 ms'nin altında kazanç vaat eden maddeleri sonraya bırakın.

Kapanış#

Lighthouse raporu, doğru okunduğunda performans işinin yol haritasıdır; yanlış okunduğunda ise anlamsız bir puan avına dönüşür. Aklınızda kalması gereken dört alışkanlık: skoru değil metrikleri hedefleyin, ağırlığı en yüksek metrikten (TBT ve LCP) başlayın, tek ölçüme güvenmeyip medyan alın ve laboratuvar sonucunu her zaman gerçek kullanıcı verisiyle birlikte değerlendirin.

Rapordaki sorunların kökü çoğu zaman sunucu tarafında düğümlenir; yavaş TTFB ve düşük işlemci gücü, kod tarafında ne yaparsanız yapın tavanı belirler. Ayrılmış kaynak isteyen projeler için VDS ve bulut sunucu paketlerimize, hazır optimize bir başlangıç için web hosting planlarımıza bakabilirsiniz. Ölçüm, teşhis ve düzeltme döngüsünü sizin yerinize yürütmemizi isterseniz sunucu yönetimi hizmetimiz tam olarak bunu yapar.