Lighthouse Rehberi: Strateji, Ölçüm ve İpuçları

Lighthouse, Chrome’un laboratuvar ortamında sayfayı denetleyen bir teşhis aracıdır: performans, erişilebilirlik, best practices ve SEO kategorilerinde bulgu üretir. Bu rehber Lighthouse’u “sıralama skoru” veya tek SEO denetimi gibi değil; lab teşhis stratejisi, kategori okuma, performans bütçesi ve CI/regresyon disiplini olarak konumlandırır. Resmi giriş için web.dev Lighthouse ve metrikler için web.dev vitals güncel kaynaktır.

PSI raporlarında skor kovalama ve lab/field ayrımı için PageSpeed Insights hataları yazısına gidin — oradaki açı rapor ve alan verisi; buradaki açı geliştirme döngüsünde Lighthouse’u nasıl stratejik kullanacağınız. CWV önceliği için Core Web Vitals kontrol listesi ile hizalanın.

Bölüm 1Lighthouse’un lab teşhis rolü ve sınırları

Lab ortamı koşulları kontrol eder: cihaz emülasyonu, ağ kısıtı, CPU yavaşlatma. Bu, yeniden üretilebilir karşılaştırma sağlar — gerçek kullanıcı dağılımının yerine geçmez. Lab verisinin sınırları: tek (veya az) koşu profili, soğuk/sıcak önbellek farkı, kişiselleştirme ve üçüncü parti dalgalanması, “gerçek kullanıcıda hiç görülmeyen” fırsat uyarıları. Strateji: Lighthouse ile “bu değişiklik şablonu iyileştirdi mi / bozdu mu?” sorusuna cevap arayın; “tüm ülkelerde kullanıcılar böyle hissediyor” iddiası kurmayın.

• İyi kullanım: PR öncesi aynı URL’de tekrarlanabilir lab koşusu
• Kötü kullanım: tek koşunun skorunu yönetim KPI’sı veya yayın kapısı yapmak
• Not: eklentiler, A/B, kimlik durumu lab sonucunu oynatabilir — koşu ortamını sabitleyin

Aynı şablon için “logged-out / boş sepet” gibi kararlı bir durumu seçin. Kişiselleştirilmiş hero veya rastgele banner lab koşularını karşılaştırılamaz hale getirir. Teşhis stratejisi önce kararlı sahneyi, sonra değişikliği ölçmektir — her koşuda farklı içerikle skor okumak gürültüdür.

Bölüm 2Lab ile alan verisini karıştırmamak

Alan (field) verisi — CrUX ve benzeri gerçek kullanıcı ölçümleri — cihaz, ağ ve etkileşim çeşitliliğini taşır. Lab iyi görünüp alan kötü kalabilir; tersi de mümkündür (ör. lab’da ağır üçüncü parti engelli, alanda açık). Bu yüzden Lighthouse çıktısını CrUX / Search Console deneyim raporunun yerine koymayın. Geliştirici regressiyonu lab ile; kullanıcı deneyimi iddiası alan ile konuşulur. İkisini aynı slaytta “hız skorumuz” diye birleştirmeyin.

Bölüm 3Core Web Vitals ile ilişki

Lighthouse performans denetimleri LCP, CLS ve etkileşim (INP / eski metrikler) adaylarını lab koşullarında yüzeyler; Core Web Vitals ise alan eşikleriyle okunan deneyim metrikleridir. İlişki: lab, hangi kaynak veya düzenin LCP/CLS’yi bozduğunu teşhis etmek için kullanılır; CWV “kullanıcıda eşiği geçtik mi?” sorusudur. Lab’da LCP fırsatını kapatmak alan LCP’yi iyileştirebilir — garanti değildir. Öncelik sırası için Core Web Vitals kontrol listesi ve web.dev vitals ile hizalanın; Lighthouse skor yüzdesini CWV proxy’si sanmayın.

Bölüm 4Kategorileri ve audit bulgularını yorumlamak

Performans: LCP, INP (veya eski etkileşim metrikleri), CLS adayları ve fırsat/uyarı listeleri. Erişilebilirlik: kontrast, ad, yapısal bulgular — otomatik tarama sınırlıdır; manuel kontrol gerekir. Best practices: güvenlik ve modern API hijyeni ipuçları. SEO kategorisi: temel tarama/robots/viewport gibi dar kontroller. Her bulguyu “SEO backlog”a atmak yerine sahip ekibe yönlendirin: performans → front-end, a11y → tasarım+FE, SEO kategorisi → teknik SEO ile birlikte yorum.

Audit yorumunda “opportunity” listesini skor avına çevirmeyin: her uyarı eşit ağırlıkta değildir. Önce şablon kök nedenine indirgeyin (tek LCP görseli, tek engelleyici script, düzen kaydıran banner). Küçük tasarruf uyarılarını yeşil skor için peş peşe kovalamak, ürün değerini düşüren mikro optimizasyon borcu üretir. Yeşil SEO kategorisi, sitenin arama stratejisinin bittiği anlamına gelmez. Teknik SEO kritik kontroller ve crawl araçları (Screaming Frog uygulamaları) Lighthouse’un görmediği keşif ve indeks meselelerini taşır.

Erişilebilirlik kategorisinde de benzer sınır vardır: otomatik denetim kontrast ve bazı ad sorunlarını yakalar; klavye tuzağı, anlam bütünlüğü veya karmaşık widget davranışı için manuel tur şarttır. Kategoriyi “yeşil = bitti” diye kapatmak hem a11y hem SEO tarafında kör nokta bırakır.

Bölüm 5Tek skorla karar vermemek

0–100 performans skoru iletişim kolaylığı sağlar; karar ölçüsü olmamalıdır. Skor, metrik ağırlıklarının sentezidir; tek koşuda oynar, form faktörüne göre değişir ve “100” ile “kullanıcı mutlu” eşleşmez. Yayın kapısı, yönetim KPI’sı veya “SEO sağlığı” olarak tek Lighthouse skorunu kullanmayın. Bunun yerine: bütçe (kaynak/metrik), bozulan kritik audit’ler, alan CWV trendi ve görev tamamlanabilirliği. Skor sunum kapağı olabilir; karar kaydı olamaz.

Bölüm 6Performans bütçesini şablona bağlamak

Bütçe; “mümkün olduğunca hızlı” yerine sayılabilir eşiktir: örneğin belirli şablonda JS transfer üst sınırı, görsel ağırlık, LCP için kabul bandı. Bütçe olmadan her yeni widget lab skorunu sessizce yer. Çözüm: şablon sınıfı başına bütçe yazın; aşımı PR’da görünür kılın. Bütçe ürün kararıdır — pazarlama “bir pixel daha” isteğini teknik borç olarak gösterir.

Bütçeyi skor yüzdesine kilitlemek yerine kaynak ve metrik diline çevirin: “ürün şablonunda ek JS +X kB aşımı” veya “LCP adayı görsel ağırlığı”. Skor tek başına gürültülüdür; kaynak bütçesi tartışmayı somutlaştırır. Yeni üçüncü parti script taleplerinde bütçe diff’i istemek, sonradan “neden yavaşladık?” sorusunu azaltır.

Lighthouse’un stratejik gücü tek seferlik audit değil, tekrarlanan koşudur. CI’da (veya düzenli pipeline’da) kritik şablon URL’lerine karşı lab koşusu: medyan skor değil, bozulan audit’ler ve bütçe aşımı ticket üretir. Yerel geliştiricide DevTools Lighthouse ile aynı hikâyeyi doğrulayın; CI ortam farkını belgeleyin. Amaç “100 almak” değil, regresyonu erken görmektir.

• Kritik şablonları seçin (ana, kategori, ürün, blog şablonu) — tüm siteyi her commit’te taratmayın
• Eşikleri sert “100”e kilitlemek yerine bütçe ve trend kullanın
• Flaky koşuları (ağ, üçüncü parti) için yeniden deneme ve üçüncü parti engelleme politikası netleştirin

CI’da staging URL’leri ile prod’u körlemesine karşılaştırmayın: farklı içerik, farklı cache ve farklı üçüncü parti durumu lab farkı üretir. Karşılaştırma sözleşmesi yazın — hangi ortam, hangi form faktörü, hangi throttling. Regresyon uyarısı geldiğinde önce ortamı, sonra kodu suçlayın.

Bölüm 7Lab çıktısını alan ve SEO yığınıyla yan yana okumak

Lab iyileşmesi alan verisine gecikmeli yansıyabilir; hiç yansımayabilir (farklı cihaz karması). Yerel ölçüm için Core Web Vitals testi ve site hız testi tamamlayıcıdır. Hiçbiri Lighthouse CI bütçesinin yerine geçmez; hiçbiri de tek başına “SEO bitti” veya “tek skor yeterli” demez.

PSI makalesiyle sınır: orada skor kovalama ve lab/field okuma disiplini; burada CI, kategori sahipliği ve bütçe. İkisini aynı “hız yazısı”na sıkıştırmak hem cannibalization hem de ekip rol karışıklığı üretir. Geliştirici regressiyonu Lighthouse ile; SEO rapor dili PSI/alan süreciyle yönetilsin.

İpucu seti: koşu profilini kaydedin; aynı URL’yi üç kez çalıştırıp medyan alın; “opportunity” listesini şablon kök nedenine indirgeyin (tek görsel, tek script); SEO kategorisini crawl programınızla karıştırmayın; skoru sunum kapağı yapmayın. Lighthouse, iyi kullanıldığında geliştirme döngüsünün lab aynasıdır — arama motorunun resmi puan kartı değildir.