Paniğe kapılmadan Lighthouse raporu nasıl okunur

İlk kural: puanınız siteniz değildir

Bir Lighthouse raporunu ilk kez açtığınızda karşınıza sayılarla, renk kodlu kutularla ve daha önce hiç duymadığınız şeylere dair uyarılarla dolu bir duvar çıkar. Doğal tepki paniktir. Puan kırmızıdır. On yedi denetim başarısız olmuştur. Site kesin bozuk olmalı, değil mi?

Muhtemelen değildir. Lighthouse bir tanılama aracıdır, karne değildir. Puan, laboratuvar koşullarında çalıştırılan sentetik bir kıyaslamadır; çoğu zaman kısıtlanmış bir bağlantıda, 2017’den kalma orta segment bir telefonu simüle eder. Sitenizin o belirli senaryoda nasıl performans gösterdiğini söyler; gerçek kullanıcıların sahada onu nasıl deneyimlediğini değil.

Bu önemlidir, çünkü çoğu ekip puana takılıp bağlamı kaçırır. Gerçek zamanlı veri kullanan karmaşık bir web uygulaması için 65 puan gayet kabul edilebilir olabilir. 95 puan ise yanlış şeyler optimize edildiyse hâlâ kötü bir deneyim sunabilir. Puan, başarı metriği değil, inceleme için bir başlangıç noktasıdır.

Önce ne okunmalı: Core Web Vitals

Genel performans puanını geçin. Metrics bölümüne kaydırın ve üç sayıya bakın: Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS) ve Interaction to Next Paint (INP). Bunlar Core Web Vitals metrikleridir ve Google’ın sıralama sinyali olarak kullandığı tek performans metrikleridir.

• LCP, en büyük görünür öğenin render edilmesinin ne kadar sürdüğünü ölçer. Hedef: 2,5 saniyenin altı. 4 saniyenin üzerindeyseniz kullanıcılar anlamlı içeriği görmek için fazla uzun bekliyordur.
• CLS, görsel kararlılığı ölçer: sayfanın yüklenirken ne kadar zıpladığını. Hedef: 0,1’in altı. 0,25’in üzerindeyseniz kullanıcılar, düğmeler yer değiştirdiği için yanlışlıkla yanlış şeye tıklıyordur.
• INP, yanıt verebilirliği ölçer: sayfanın tıklamalara, dokunmalara ve tuş vuruşlarına ne kadar hızlı tepki verdiğini. Hedef: 200ms’nin altı. 500ms’nin üzerindeyseniz site ağır hissedilir.

Bu üç metrik gerçek kullanıcı hayal kırıklığıyla ilişkilidir. Başka bir şeyle uğraşmadan önce bunları düzeltin.

Fırsatlar ve tanılamalar: farkı bilin

Lighthouse bulgularını iki kategoriye ayırır: Fırsatlar ve Tanılamalar. Fırsatlar, tahmini zaman tasarrufuna göre sıralanır. Tanılamalar ise ek bağlamdır; sorun olabilecek ya da olmayabilecek şeylerdir.

Fırsatlarla başlayın. Lighthouse, "Render engelleyici kaynakları ortadan kaldırın" diyerek 1,2 saniye kazandırabileceğini söylüyorsa bu somut bir kazanımdır. "Kullanılmayan JavaScript’i azaltın" diyerek 0,1 saniye kazandırabileceğini söylüyorsa muhtemelen refaktöre değmez.

Tanılamalar daha zordur. "Aşırı DOM boyutundan kaçının" kulağa kötü gelir, ancak CLS’iniz iyiyse ve INP’niz hızlıysa büyük bir DOM kimseye zarar vermiyor olabilir. Tanılamalar ipucudur, zorunluluk değil. Gerçek metriklerinizle uyumlu olanları araştırın.

Genellikle görmezden gelebileceğiniz denetimler

Bazı Lighthouse uyarıları eski kalmış ya da aşırı agresiftir. En fazla gereksiz paniğe yol açanlar şunlardır:

• "Kaydırma performansını iyileştirmek için pasif dinleyiciler kullanmıyor" — Bu, çoğu zaman sonucu anlamlı biçimde değiştirmeyen bir mikro optimizasyondur. Takılmalı kaydırmaya dair kanıtınız yoksa geçin.
• "Görsel öğelerinde açık width ve height yok" — Bu CLS için önemlidir, ancak yalnızca görseller düzen kaymalarına neden oluyorsa. CLS’iniz zaten iyiyse yalnızca denetim uğruna refaktör yapmayın.
• "Görselleri yeni nesil formatlarda sunun" — Evet, WebP ve AVIF daha küçüktür. Ancak görselleriniz zaten optimize edilmişse ve LCP’niz hızlıysa bu bir kriz değil, olsa iyi olur türünden bir iyileştirmedir.
• "Çok büyük ağ yüklerinden kaçının" — Lighthouse 1,6 MB üzerindeki her şeyi işaretler. Ancak hızlı yüklenen 2 MB’lık bir sayfa, render etmeyi engelleyen 500 KB’lık bir sayfadan iyidir. Yalnızca toplam bayta değil, baytların nasıl teslim edildiğine odaklanın.

Her şey kırmızı olduğunda ne yapmalı

Lighthouse puanınız 50’nin altındaysa ve denetimlerin çoğu başarısız oluyorsa muhtemelen üç temel nedenden biriyle karşı karşıyasınız:

1. Optimize edilmemiş fontlar. Web fontları çoğu sitede hâlâ en kolay performans kazanımıdır. Yalnızca ikisini kullanırken altı font ağırlığı yükleyip yüklemediğinizi ya da WOFF2 yerine WOFF dosyaları gönderip göndermediğinizi kontrol edin.
2. Render engelleyici CSS ve JavaScript. First Contentful Paint (FCP) değeriniz 3 saniyenin üzerindeyse bir şey tarayıcının boyama yapmasını engelliyordur. <head> içinde büyük CSS dosyaları veya senkron betikler arayın.
3. Aşırı büyük görseller. LCP öğeniz bir görselse ve 4 MB ise sorun budur. Sıkıştırın, ekranın altındaki görselleri lazy-load ile yükleyin ve responsive image söz dizimi kullanın.

Bunlardan birini düzeltin ve Lighthouse’u yeniden çalıştırın. Çoğu zaman 20-30 puanlık bir sıçrama görürsünüz. Sonra sıradakine geçin.

Laboratuvar verisi ve saha verisi: gerçeklik kontrolü

Lighthouse laboratuvarda çalışır. Yavaş bir bağlantıyı ve yavaş bir cihazı simüle eder, ancak gerçek kullanıcı davranışını simüle edemez: insanların nasıl kaydırdığını, neye tıkladığını, kesintili Wi-Fi’da olup olmadıklarını.

Gerçeklik kontrolü için Lighthouse sonuçlarınızı Chrome User Experience Report (CrUX) içindeki saha verileriyle karşılaştırın. CrUX, gerçek Chrome kullanıcılarının sitenizi son 28 günde nasıl deneyimlediğini gösterir. Lighthouse LCP’nizin 4 saniye olduğunu söylüyor ama CrUX 2 saniye gösteriyorsa CrUX’a güvenin. İkisi de kötüyse gerçek bir sorununuz var demektir.

CrUX verilerini PageSpeed Insights’ta (Lighthouse’un web sürümü) veya Google Search Console’da "Core Web Vitals" altında bulabilirsiniz. Uyuşmazlık varsa nedenini araştırın. Belki gerçek kullanıcılarınız daha hızlı ağlardadır. Belki Lighthouse optimize edilmemiş bir geliştirme derlemesini test ediyordur.

Lighthouse ne zaman yeniden çalıştırılmalı

Lighthouse gürültülüdür. Art arda üç kez çalıştırın; aynı sayfada bile üç farklı puan alırsınız. Bunun nedeni performansın değişken olmasıdır: arka plan süreçleri, ağ jitter’ı ve tarayıcı sezgisel kuralları sonucun tamamını etkiler.

Kararlı bir temel değer elde etmek için Lighthouse’u tüm uzantılar devre dışı bırakılmış şekilde gizli modda çalıştırın veya daha tutarlı sonuçlar için --preset=desktop bayrağıyla CLI kullanın. Üç kez çalıştırın ve puanların ortalamasını alın. Büyük dalgalanmalar görüyorsanız (10 puandan fazla), başka bir şey ters gidiyordur; belki sunucu yavaştır ya da sayfa her seferinde farklı kaynaklar yüklüyordur.

Her önemli değişiklikten sonra Lighthouse’u yeniden çalıştırın. Yeni bir font stratejisi mi dağıttınız? LCP’yi kontrol edin. Görselleri lazy-load mu yaptınız? CLS’i kontrol edin. Üçüncü taraf betik mi eklediniz? INP’yi kontrol edin. Performans tek seferlik bir düzeltme değildir; savunduğunuz bir bütçedir.

Lighthouse bulgularını uygulamaya geçirmenize yardımcı olan araçlar

Lighthouse size neyin yavaş olduğunu söyler. Bunu nasıl düzelteceğinizi her zaman söylemez. Bunun için ek araçlara ihtiyacınız vardır:

• WebPageTest, sayfanın nasıl yüklendiğini kare kare gösteren bir film şeridi görünümü sunar. LCP ve CLS sorunlarını tanılamak için vazgeçilmezdir.
• Chrome DevTools Performance panel, ana iş parçacığını tam olarak hangi JavaScript’in engellediğini gösterir. Kötü bir INP puanının kaynağını bulmak için kullanın.
• Görsel sıkıştırma araçları, görselleri doğrudan tarayıcıda optimize etmenizi sağlar; bu, üçüncü taraf bir servise yüklemekten daha hızlı ve daha gizlidir. İstemci taraflı görsel işleme gizlilik açısından kazançtır, çünkü görselleriniz makinenizden hiç ayrılmaz.

Lighthouse başlangıç noktasıdır. Bu araçlar işi bitirmenize yardımcı olur.

Öne çıkan çıkarımlar

• Lighthouse puanınız bir laboratuvar kıyaslamasıdır; gerçek dünyadaki kullanıcı deneyiminin ölçüsü değildir. Paniğe kapılmadan önce CrUX saha verileriyle karşılaştırın.
• Önce Core Web Vitals’a (LCP, CLS, INP) odaklanın. Bunlar kullanıcı hayal kırıklığı ve SEO etkisiyle ilişkili metriklerdir.
• Fırsatları tahmini zaman tasarrufuna göre önceliklendirin. Gerçek performans sorunlarınızla örtüşmeyen Tanılamaları görmezden gelin.
• Pasif dinleyiciler veya yeni nesil görsel formatları gibi bazı denetimler mikro optimizasyonlardır. Önce büyük şeyleri düzeltin.
• Lighthouse’u üç kez çalıştırın ve sonuçların ortalamasını alın. Performans değişkendir ve tek bir çalıştırma yanıltıcı olabilir.

SSS

S: Lighthouse puanım neden her çalıştırdığımda değişiyor?
C: Lighthouse performansı değişken koşullar altında ölçer; ağ hızı, CPU yükü ve tarayıcı sezgisel kuralları sonucun tamamını etkiler. Daha kararlı bir temel değer için gizli modda üç kez çalıştırın ve puanların ortalamasını alın.

S: Önce mobil için mi masaüstü için mi optimize etmeliyim?
C: Mobil. Lighthouse varsayılan olarak mobil simülasyon kullanır, çünkü web trafiğinin çoğu mobildir ve mobil cihazlar daha yavaştır. Mobil puanınız iyiyse masaüstü puanınız genellikle iyi olur.

S: Lighthouse puanım 95, ama sitem hâlâ yavaş hissettiriyor. Sorun ne?
C: Lighthouse, yüklemeden sonraki etkileşimi değil, sayfa yüklemesini ölçer. INP puanınızı kontrol edin ve kullanıcılar tıkladığında ya da kaydırdığında ne olduğunu profillemek için Chrome DevTools Performance panel’i kullanın. Lighthouse’un yakalayamadığı bir JavaScript sorununuz olabilir.

S: Kusursuz 100 puana ihtiyacım var mı?
C: Hayır. 90+ puan mükemmeldir. 100’ün peşinden koşmak çoğu zaman kullanıcılar için önemli olmayan şeyleri optimize etmek anlamına gelir. Gerçek metriklere —LCP, CLS, INP— odaklanın ve puanı görmezden gelin.

S: Çok sayıda üçüncü taraf betik kullanıyorsam Lighthouse’a güvenebilir miyim?
C: Lighthouse üçüncü taraf betikleri sorun olarak işaretler, ancak gerekli olanlarla gereksiz olanları her zaman ayırt edemez. En kötü ihlalcileri belirlemek için "Çok büyük ağ yüklerinden kaçının" ve "JavaScript yürütme süresini azaltın" denetimlerini kullanın; ardından bunları tutmaya değip değmeyeceğine karar verin.

Kaynaklar

• "Lighthouse performance scoring" — Google Developers
• "Core Web Vitals" — web.dev
• "Chrome User Experience Report" — Google Developers
• "WebPageTest Documentation" — WebPageTest.org