Lighthouse ile Frontend Performans Denetimi

Lighthouse, Google'ın açık kaynaklı denetim aracıdır ve bir web sayfasının performansını, erişilebilirliğini, en iyi uygulamalara uyumunu ve SEO'sunu otomatik olarak puanlar. Ama çoğu kişi sadece o yuvarlak performans skoruna bakıp paniğe kapılır. Oysa skor, asıl hikâyenin sadece özetidir. Bu yazıda raporu nasıl okuyacağınızı, hangi metriklerin gerçekten kullanıcı deneyimini belirlediğini ve tespit ettiğiniz darboğazları nasıl adım adım gidereceğinizi anlatıyorum.

Lighthouse raporunu nasıl çalıştırırsınız

Lighthouse'a ulaşmanın birkaç yolu var; en doğrusu, kullanım senaryonuza uygun olanı seçmektir:

• Chrome DevTools > Lighthouse sekmesi: Hızlı, görsel ve yerelde çalışır. Ancak makinenizin CPU'su ve ağı sonucu etkiler.
• PageSpeed Insights (pagespeed.web.dev): Aynı motoru kullanır ama Google'ın sunucularında çalışır ve gerçek kullanıcı verisini (CrUX / Field Data) de gösterir.
• CLI: Otomasyon için idealdir. npx lighthouse https://aslain.dev --view komutu raporu üretir ve tarayıcıda açar.

Önemli bir nokta: ölçümü her zaman gizli pencerede ve eklentiler kapalıyken yapın. Reklam engelleyiciler ve diğer uzantılar sayfaya kod enjekte ederek skoru çarpıtır. Ayrıca tek bir ölçüme güvenmeyin; performans değişkendir, 3-5 kez çalıştırıp medyan sonuca bakın.

Lab verisi mi, saha verisi mi?

Lighthouse iki tür veri sunar ve bunları karıştırmak en sık yapılan hatadır. Lab verisi (DevTools/Lighthouse) kontrollü, simüle edilmiş bir ortamda tek bir yüklemeyi ölçer; tekrarlanabilir ama yapaydır. Saha verisi (Field Data / Core Web Vitals) ise son 28 günde sitenizi gerçekten ziyaret eden kullanıcıların Chrome'dan toplanan anonim ölçümleridir. Google sıralamasında dikkate aldığı şey saha verisidir. Yani lab skorunuz 100 olsa bile, saha verisi kötüyse asıl sorun çözülmemiş demektir.

Hangi metrikler önemli: LCP, CLS ve TBT

Performans skoru ağırlıklı bir ortalamadır; en çok katkıyı şu metrikler verir:

• LCP (Largest Contentful Paint): Görünür alandaki en büyük öğenin (genelde hero görseli veya başlık) çizilme süresi. Hedef: 2.5 sn altı.
• CLS (Cumulative Layout Shift): Sayfa yüklenirken öğelerin beklenmedik kayması. Hedef: 0.1 altı.
• TBT (Total Blocking Time): Ana iş parçacığının JavaScript yüzünden kullanıcı etkileşimine kapalı kaldığı süre. Sahadaki karşılığı INP'tir. Hedef: 200 ms altı.
• FCP ve Speed Index: İlk içeriğin ve görsel doluluğun hızı.

Raporda her metriğin yanındaki rengi (yeşil/turuncu/kırmızı) ve "Opportunities" ile "Diagnostics" bölümlerini birlikte okuyun. Skorun kendisi değil, bu maddeler size ne yapacağınızı söyler.

LCP darboğazını gidermek

LCP genellikle büyük bir görselden ya da geç yüklenen yazı tipinden kaynaklanır. Pratik adımlar:

• Hero görselini modern formata (WebP/AVIF) çevirin ve doğru boyutta sunun. 3000px genişliğindeki bir görseli 800px'lik bir alanda göstermeyin.
• Kritik görseli erkenden bulması için tarayıcıya ipucu verin:

<link rel="preload" as="image"
      href="/img/hero.avif"
      fetchpriority="high">

Yazı tipleri için font-display: swap kullanın ki metin, font inerken görünmez kalmasın. Sunucu yanıt süresi (TTFB) de LCP'yi doğrudan etkiler; ağır sorguları önbelleğe alın ve mümkünse CDN kullanın. Aşağıdaki birkaç maddenin etkisi genelde büyüktür ama her sitede sıra değişir; raporun size gösterdiği LCP öğesini açıp gerçek nedenini bulun.

CLS ve TBT'yi düşürmek

CLS için altın kural: yer kaplayan her öğeye baştan boyut verin. Görsellere width ve height öznitelikleri ekleyin (tarayıcı oranı hesaplayıp yer ayırır), reklam/embed alanlarına sabit yükseklik tanımlayın ve içeriği yukarıdan iten geç gelen banner'lardan kaçının. Web fontlarının neden olduğu kaymayı azaltmak için size-adjust ve yedek font eşleştirmesi yardımcı olur.

TBT ise neredeyse her zaman JavaScript fazlalığıdır. Yapılacaklar:

• Kullanılmayan JS'i ayıklayın; "Reduce unused JavaScript" uyarısını ciddiye alın.
• Üçüncü taraf scriptleri (analytics, chat, reklam) async ya da defer ile yükleyin, mümkünse etkileşim sonrasına erteleyin.
• Büyük paketleri code splitting ile bölün; sadece o sayfada gereken kodu gönderin.

<script src="/js/app.js" defer></script>
<script src="https://analytics.example.com/s.js" async></script>

Denetimi alışkanlığa dönüştürmek

Performans tek seferlik bir iş değildir; her dağıtımda yeni bir görsel ya da script regresyona yol açabilir. Bu yüzden Lighthouse'u CI hattınıza ekleyin. Lighthouse CI ile her pull request'te eşik (budget) belirleyip, skor düşerse build'i kırabilirsiniz. Böylece "neden site yavaşladı?" sorusu, kullanıcı şikâyet etmeden önce kod incelemesinde yanıtlanır. Skoru kovalamak yerine kullanıcıyı kovalayın: gerçek cihazlarda, gerçek ağ koşullarında test edin.

Sık Sorulan Sorular

Lighthouse skorum neden her seferinde değişiyor?

Çünkü lab ölçümü makinenizin o anki CPU yükünden, ağ koşullarından ve arka plan süreçlerinden etkilenir. Bu yüzden gizli pencerede 3-5 ölçüm alıp medyan değeri kullanmak, tek bir skora güvenmekten çok daha sağlıklıdır.

100 puan almam şart mı?

Hayır. 100, hoş bir hedeftir ama asıl önemli olan Core Web Vitals eşiklerini (LCP < 2.5 sn, CLS < 0.1, INP < 200 ms) saha verisinde geçmektir. 92 puanlı ama saha verisi "iyi" olan bir site, 99 puanlı ama saha verisi kötü bir siteden üstündür.

Mobil ve masaüstü skorları neden bu kadar farklı?

Lighthouse mobil testte yavaş bir cihazı ve kısıtlı ağı simüle eder. Kullanıcılarınızın çoğu mobilden geldiği için mobil skoru öncelikle iyileştirmek gerekir.

Sitenizin performansını ciddiye almak ister misiniz? Lighthouse raporunuzu birlikte okuyup LCP, CLS ve TBT darboğazlarını kalıcı biçimde çözebiliriz. Benimle iletişime geçin ve sitenizin hız analizine başlayalım.