CrUX ve Lighthouse Verileri Birlikte Nasıl Okunur?

Aynı sayfa için iki farklı performans sonucu görmek kafa karıştırır. Biri “iyi” derken diğeri “zayıf” diyorsa, sorun araçlarda değil; verinin neyi ölçtüğündedir.

CrUX ile Lighthouse verilerini doğru okumak, puan bakmaktan daha değerlidir. Çünkü biri gerçek kullanıcı deneyimini gösterir, diğeri sorunun kaynağını bulmanıza yardım eder. Asıl farkı anladığınızda, raporlardaki çelişki bir sorun değil, teşhis avantajı olur.

CrUX ile Lighthouse neden farklı konuşur?

CrUX, gerçek Chrome kullanıcılarından gelen alan verisidir. Veriler tek bir andan değil, son 28 günlük kullanımın toplulaştırılmış halinden gelir. Core Web Vitals değerlendirmesi de genelde 75. persentile göre yapılır. Yani iyi çıkan sonuç, ortalama bir anı değil; kullanıcıların büyük bölümünün yaşadığı deneyimi anlatır.

Lighthouse ise laboratuvar testidir. Sayfayı kontrollü koşullarda açar ve tekil bir senaryoda ölçüm yapar. Bu yüzden çok iyi bir teşhis aracıdır. Fakat tek başına “kullanıcılar sitede ne yaşıyor” sorusuna tam cevap vermez.

Aşağıdaki kısa tablo, ayrımı netleştirir:

Nokta	CrUX	Lighthouse	Nasıl yorumlanır?
Veri türü	Gerçek kullanıcı verisi	Kontrollü test verisi	Biri deneyimi ölçer, diğeri nedeni arar
Zaman penceresi	Son 28 gün	Tek test anı	Düzeltmeler CrUX’a geç yansır
Kapsam	Trafiği olan URL veya origin	Test edilen sayfa	Düşük trafikte sayfa yerine origin verisi görülebilir
Güçlü tarafı	Etkilenmiş kullanıcı oranını gösterir	Sorunlu kaynakları işaret eder	İkisi birlikte okunmalıdır

Bu yüzden PageSpeed Insights ekranında iki veri türünü yan yana görmek faydalıdır. Alan verisi kötü, laboratuvar verisi iyi olabilir. Tersi de olabilir. Her iki durumda da ilk soru aynı olmalı: “Bu veri, hangi koşulda toplandı?”

Alan verisi ile laboratuvar verisi ayrımını daha derli toplu görmek isterseniz, alan verisi ile laboratuvar verisi farkı açıklaması iyi bir referanstır.

LCP, INP ve CLS birlikte okununca daha çok şey söyler

Üç ana metrik aynı problemi anlatmaz. Bu yüzden CrUX ile Lighthouse sonuçlarını yorumlarken önce metriğin doğasına bakın.

LCP, ana içeriğin ne kadar hızlı göründüğünü ölçer. Genel eşik, 2,5 saniye altıdır. CrUX’ta kötü LCP görüyorsanız, gerçek kullanıcıların önemli bir kısmı sayfanın ana içeriğini geç görüyor demektir. Lighthouse’ta kötü LCP ise hangi öğenin geç yüklendiğini, sunucu yanıtının mı, render engelleyici kaynakların mı, yoksa büyük görsellerin mi etkili olduğunu bulmanıza yardım eder.

INP, etkileşime verilen tepkiyi ölçer. İyi kabul edilen seviye 200 ms altıdır. Buradaki fark çok kritiktir. Lighthouse genelde kısa ve sınırlı etkileşimler test eder. Oysa CrUX, gerçek kullanıcıların filtre açması, sepete eklemesi, menü kullanması gibi davranışları da yansıtır. Bu yüzden INP tarafında CrUX çoğu zaman daha dürüst konuşur.

CLS, görsel düzen kaymasını ölçer. İyi eşik 0,1 altıdır. Laboratuvar testinde temiz görünen bir sayfa, gerçek kullanıcıda reklam, çerez bandı, geç yüklenen font veya sonradan eklenen bileşen yüzünden kötüleşebilir. CLS’te alan verisi çoğu zaman sonradan olan hareketleri yakalar.

Pratik bir okuma mantığı kurun. LCP, “ilk görünüm” sorunudur. INP, “kullanım anı” sorunudur. CLS ise “sayfa açıldıktan sonra oynayan düzen” sorunudur. Aynı raporda üç metriği tek sepete atarsanız, yanlış teşhis koyarsınız.

CrUX kötü ama Lighthouse iyi çıkarsa ne anlama gelir?

Bu senaryo sahada sık görülür. Üstelik en öğretici durumlardan biridir. Çünkü laboratuvarda temiz görünen sayfa, gerçek dünyada kullanıcıya sorun yaşatıyordur.

LCP örneği: Lighthouse 2,1 saniye gösteriyor, CrUX 3,4 saniye. Bu fark çoğu zaman ağ kalitesi, cihaz gücü, bölgesel gecikme, oturum açmış kullanıcı akışları ya da değişken sunucu yanıtı yüzünden oluşur. Test ortamı temizdir; gerçek trafik öyle değildir.

INP örneği: Lighthouse iyi, CrUX kötü. Burada ilk şüphe, kullanıcıların yaptığı karmaşık etkileşimlerdir. Filtreleme, sonsuz kaydırma, modal açılışı, canlı arama kutusu, üçüncü taraf script’ler ve uzun JavaScript görevleri bu tabloyu üretir. Çünkü laboratuvar testi tek yüklemeyi görür, gerçek kullanıcı ise sayfayı kullanır.

CLS örneği: Lighthouse temiz, CrUX kötü. Geç gelen reklam alanları, boyutsuz görseller, A/B test araçları, sonradan açılan izin katmanları ve kişiselleştirme öğeleri öne çıkar. Laboratuvar testi bazen bu davranışları hiç tetiklemez.

CrUX kötüyse, sorun kullanıcıda yaşanıyordur. O nedenle laboratuvarda görünmeyen koşulları aramak gerekir.

Burada en sık yapılan hata, Lighthouse puanı iyi diye sorunu küçümsemektir. Doğru yaklaşım, etkilenen kullanıcı segmentini bulmaktır. Mobilde mi kötü, belli ülkelerde mi kötü, sadece giriş sonrası sayfalarda mı kötü, yoksa tek bir şablonda mı kötü? Sayfa düzeyi veri yoksa origin verisi de yanıltabilir. Birkaç kötü şablon, tüm alan adının raporunu aşağı çekebilir.

Bir ayrıntı daha önemli: CrUX anlık değildir. Bugün yaptığınız düzeltme, yarın rapora tam güçte yansımaz. Bu gecikmeyi hesaba katmadan karar verirseniz, erken hüküm verirsiniz.

Lighthouse kötü ama CrUX iyi çıkarsa ne yapılmalı?

Bu tablo daha az korkutucudur ama göz ardı edilmemelidir. Çünkü Lighthouse bazen henüz kullanıcı kitlesine tam yansımamış riski erken gösterir.

En yaygın durum, sentetik testin daha sert koşullarda çalışmasıdır. Soğuk önbellek, zayıf CPU simülasyonu ve tekil ağ profili, sayfayı olduğundan ağır gösterebilir. Gerçek kullanıcıların çoğu daha iyi cihaz kullanıyorsa veya tekrar ziyaretle önbellekten faydalanıyorsa, CrUX iyi kalabilir.

Bir başka neden, sorunlu sayfanın trafik payının düşük olmasıdır. Lighthouse kötü gördüğünüz URL, henüz yeterli kullanıcı hacmine ulaşmadıysa CrUX tarafında görünmez. Bazen de sayfa düzeyinde veri yoktur ve siz origin verisine bakarsınız. O durumda sağlam şablonlar, sorunlu URL’yi maskeler.

Bu senaryoda yapılacak iş, laboratuvar sonucunu çöpe atmak değildir. Önce testi birkaç kez tekrar edin. Sonra aynı şablonda farklı URL’leri ölçün. Ardından yalnızca ilk yüklemede mi, etkileşim sonrası mı bozulduğunu ayırın. Eğer kötüleşme tutarlıysa, bu bir regresyon sinyalidir.

Sunucu dalgalanması, yanıt süresi sıçramaları veya saat bazlı sorunlar LCP tarafını bozuyorsa, teknik SEO için tarama istatistiklerini okuma yaklaşımı altyapı davranışını anlamada işe yarar. Benzer şekilde, CrUX ile laboratuvar sonuçlarını birlikte ele alan CrUX ve Lighthouse karşılaştırma rehberi da iyi bir çapraz kontrol sunar.

Veri uyuşmazlığında en kısa teşhis akışı

Karışık görünen tabloyu sadeleştirmek için aynı sırayı izleyin. Bu akış, gereksiz optimizasyon yerine doğru teşhise götürür.

1. Önce kapsamı eşitleyin. Aynı URL’ye mi bakıyorsunuz, yoksa biri origin, diğeri sayfa düzeyi mi? Bu fark tek başına yanlış yorum üretir.
2. Zaman penceresini kontrol edin. Lighthouse anlıktır, CrUX son 28 günü gösterir. Deploy sonrası ilk günlerde iki veri aynı yönde gitmeyebilir.
3. Problemi metriğe göre ayırın. LCP için ağ, sunucu, kritik kaynaklar; INP için ana iş parçacığı yükü ve etkileşim akışı; CLS için sonradan eklenen öğeler öne çıkar.
4. Etkilenen grubu segmentleyin. Mobil, ülke, şablon, oturum durumu ve trafik kaynağı kırılımları çoğu zaman kök nedeni açığa çıkarır. Landing page kümelerini ayırmak için Search Console’da regex filtreleri pratik bir hız kazandırır.
5. Son olarak laboratuvarı teşhis için kullanın. Lighthouse size “kaç kullanıcı etkilendi” demez, ama “nerede bakman gerekiyor” sorusuna hızlı cevap verir.

En iyi okuma biçimi şudur: CrUX etkiyi söyler, Lighthouse nedeni aratır.

Sonuç

Aynı ekranda iki farklı sonuç görmek normaldir. Çünkü CrUX, kullanıcıların yaşadığını gösterir; Lighthouse ise sayfanın nerede tökezlediğini bulur.

Sağlıklı yorum, bu iki veriyi yarıştırmakla değil, yan yana koyup aynı teşhis zincirine bağlamakla başlar. CrUX kötüyse kullanıcı bağlamını arayın. Lighthouse kötüyse erken uyarıyı ciddiye alın. En doğru karar, verinin hangi koşulda üretildiğini unutmadan verilir.

This post may contain affiliate links. If you make a purchase through these links, I may earn a small commission at no extra cost to you.