Lighthouse testi tamamlandı: LCP 1.8 saniye, genel skor 97. Her şey yeşil. Birkaç dakika sonra Google Search Console açılıyor ve o sayfanın "Zayıf URL'ler" listesinde göründüğü görülüyor. İki araç aynı sayfayı ölçüyor; sonuçlar birbirine zıt. Hangisi doğru?

Bu durumla karşılaşan çoğu geliştirici ya Lighthouse'u ya da Search Console'u hatalı buluyor. Oysa ikisi de doğru — sadece farklı şeyleri ölçüyorlar. Lab verisi ve field data, aynı sayfanın iki ayrı yüzünü yansıtır; bu iki yüz her zaman örtüşmek zorunda değildir. Aralarındaki yapısal farkı anlamak, optimizasyon enerjisini doğru yere yönlendirmenin önkoşuludur.

Lighthouse yeşil gösterdiğinde rahatlamak mı gerekir, yoksa Search Console kırmızı gösterdiğinde harekete mi geçmek? Yanıt, her iki veri kaynağının nasıl çalıştığını bilmekten geçer.

RUM verisi neden lab ölçümünden sapabilir

Lab verisi kontrollü bir ortamda üretilir. Lighthouse çalıştırdığınızda tek bir cihaz, tek bir ağ koşulu, tek bir tarayıcı oturumu vardır. Sayfa yüklenirken başka sekme açık değildir. Geçmiş önbellek yoktur, kişiselleştirilmiş içerik yoktur, A/B testi varyantı yoktur. Bu kısıtlama bir kusur değildir; tersine, tekrarlanabilirliği garanti eder. Aynı koşulları her seferinde yeniden oluşturabilirsiniz.

Gerçek kullanıcı ise çok daha dağınık bir dünyada yaşar. Mobil bağlantıyla sayfaya gelen biri LCP'yi 4 saniyede deneyimleyebilirken, fiber hatlı masaüstü kullanıcısı aynı sayfayı 1.2 saniyede görür. Sayfayı daha önce ziyaret etmiş ve kaynakları önbellekte olan biri ile ilk kez gelen arasındaki fark 2-3 kata ulaşabilir. Kullanıcı cihazının CPU gücü, JavaScript ayrıştırma ve yürütme süresini doğrudan etkiler; Lighthouse bunu "simulated throttling" ile taklit etmeye çalışır, ama taklit gerçeğin yerini tutmaz.

RUM (Real User Monitoring), bu dağılımın tamamını toplar. Tarayıcı içinde çalışan ölçüm kodları — genellikle PerformanceObserver API'si — gerçek kullanıcı oturumlarından veri gönderir. Bu verilerin toplamı, laboratuvar koşullarından çok daha geniş bir gerçeklik kümesini temsil eder. En yaygın sapma nedenleri arasında üçüncü parti scriptlerin gerçek ortamda daha ağır yüklenmesi, CDN önbellek ısınma süreleri, kullanıcı cihaz profili dağılımı ve coğrafi farklılıklar sayılabilir. Türkiye'deki medyan kullanıcı deneyimi, Avrupa'daki bir test sunucusundan çekilen Lighthouse raporuyla hiçbir zaman tam örtüşmez.

CrUX'un yüzdelik dilim yapısı neleri gizler

Google'ın Core Web Vitals değerlendirmesi CrUX (Chrome User Experience Report) verisiyle beslenir. CrUX, Chrome tarayıcısında gerçek kullanıcıların deneyimlediği metrikleri toplar; Search Console, PageSpeed Insights'ın "Saha Verileri" sekmesi ve sıralama faktörü hesabı bu veriyle çalışır.

CrUX, bir URL için 75. yüzdelik dilim (p75) değerini raporlar. Yani sayfayı ziyaret eden kullanıcıların en yavaş %25'inin deneyimi eşik değerin altında kalmalıdır. LCP için bu eşik 2.5 saniyedir. Sayfanızın p75 LCP değeri 2.6 saniyeyse Search Console o sayfayı "Zayıf" olarak işaretler — Lighthouse skoru ne olursa olsun.

Burada önemli bir nüans vardır: p75, kullanıcılarınızın en kötü %25'ini temsil eder. Bir sayfanın ziyaretlerinin %80'i mükemmel deneyim sunarken, %20'si 3G bağlantıyla gelen mobil kullanıcılardan oluşuyor ve onlar için LCP 4 saniyeye çıkıyorsa — o sayfa hâlâ "Zayıf" kategorisinde kalabilir. Medyan değer iyiyken p75 eşiği aşılabilir; bu durum özellikle coğrafi veya cihaz dağılımı heterojen olan sitelerde sık görülür.

CrUX'un bir başka kısıtı, yeterli veri toplanamayan URL'ler için URL bazında rapor üretilmemesidir. Az trafikli sayfalar için genellikle origin düzeyinde agregat gösterilir. Sitenin genel performansı tek bir sayfanın sorununu maskeleyebilir ya da tam tersi olabilir. Bunun yanı sıra CrUX 28 günlük bir pencereye dayanır. Yaptığınız iyileştirme Search Console'a 4–6 hafta içinde yansır. Lab verisi bu gecikmeyi görmez; değişikliği test anında ölçer.

Field data yoksa lab verisi nasıl yorumlanmalı

Yeni bir proje, az trafikli bir sayfa ya da henüz yayına alınmamış bir geliştirme ortamı söz konusu olduğunda CrUX verisi oluşmamıştır. Bu durumda lab verisi tek ölçüm kaynağıdır ve bazı kabuller bilinçli biçimde yapılmalıdır.

Lighthouse'un varsayılan profili, simüle edilmiş 4G bağlantısı ve orta seviye mobil cihazı temsil eder. Masaüstü ağırlıklı bir B2B ürün üzerinde çalışıyorsanız bu profil yanıltıcı sonuçlar üretebilir. Hedef kitlenizin bağlantı hızını ve cihaz gücünü yansıtan bir konfigürasyon seçmek daha anlamlıdır. Bunun için Lighthouse'un "Device" ve "Throttling" ayarları ya da WebPageTest'in lokasyon ve cihaz seçenekleri kullanılabilir.

Tek bir ölçümden çıkarım yapmaktan kaçınmak gerekir. Lighthouse sonuçları oturumdan oturuma gürültülüdür; işlemci yükü, ağ dalgalanması, tarayıcı arka plan aktivitesi sonucu değiştirebilir. Farklı anlarda alınan 5 ölçümün medyanı, tek çalıştırmadan çok daha güvenilir bir veri noktası sağlar. Bunu otomatize etmek için lighthouse-ci CI/CD pipeline'ına entegre edilebilir; her deployment sonrasında medyan değer raporlanır ve regresyon erken yakalanır.

Lab verisini iyileştirme yönünde kullanmak mantıklıdır; ancak "bu sayfanın gerçek kullanıcı deneyimi iyidir" çıkarımını lab verisinden yapmak yanıltıcıdır. Kural şudur: lab iyileştirme sürecini yönlendirir, field data sonucu doğrular.

İki veri kaynağını birlikte okumak

Lab ve field datayı karşıt olarak değil, birbirini tamamlayan iki mercek olarak konumlandırmak gerekir. Birinin eksik bıraktığı noktayı diğeri kapatır.

Field data "sorun var mı?" sorusunu yanıtlar. Gerçek kullanıcıların ne yaşadığını gösterir. Eğer p75 CrUX değerleri eşiğin altındaysa kullanıcı deneyimi ölçülebilir olarak iyidir — Lighthouse skoru düşük bile olsa. Tersine, field data kötüyse bu, gerçek bir sorun olduğunun sinyalidir ve lab skorunu yükseltmek bu durumu değiştirmez.

Lab verisi "sorun nerede, nasıl çözülür?" sorusuna yanıt verir. Waterfall analizi, JavaScript çalıştırma süreci, render blocking kaynaklar, DOM yapısı — bunların hepsi lab ortamında incelenir. Field data size "INP yavaş" der; lab verisi "INP yavaş çünkü tıklama olayından sonra uzun bir JavaScript görevi main thread'i 400 ms boyunca bloke ediyor" der. PageSpeed Insights bu iki katmanı tek sayfada birleştirir: üstteki "Saha Verileri" bölümü CrUX'tan, alttaki "Tanılamalar" ve "Fırsatlar" bölümü lab ölçümünden beslenir.

İkisini birlikte okuyunca tablo netleşir: field data sorun olduğunu doğruluyorsa, lab verisindeki önerileri önceliklendirmek anlamlıdır. Field data iyiyse, lab skorunu daha da yükseltmeye harcanan efor gerçek kullanıcıya yansımayabilir. Search Console veya CrUX'ta bir metrikte gerileme görüldüğünde lab ortamına geçip kök nedenini aramak, ardından deployment sonrasında field data ile doğrulamak — bu döngü en verimli çalışma biçimidir.

Hangi kararda hangi veri kaynağına güvenilmeli

Sıralama etkisi söz konusu olduğunda field data belirleyicidir. Google'ın sıralama sistemi CrUX verisiyle çalışır. Lighthouse skoru doğrudan bir sıralama faktörü değildir. "Lighthouse 100 aldım, neden sıralamam etkilenmiyor?" sorusunun yanıtı açıktır: p75 CrUX değerleri eşiği geçmiyorsa Lighthouse skoru bu karar açısından anlamsızdır.

Hangi sayfada, hangi metrikte, hangi kullanıcı segmentinde sorun yaşandığını saptamak için de field data şarttır. TTFB değerlerinin belirli bir coğrafyada yüksek olduğunu ya da CLS sorunun yalnızca mobilde görüldüğünü Lighthouse ile tespit edemezsiniz. Bu tür segmentasyon yalnızca RUM veya CrUX üzerinden mümkündür.

Regresyon tespiti ve aktif geliştirme sürecinde ise lab verisi daha hızlı ve kontrollüdür. Bir değişikliğin LCP'yi etkileyip etkilemediğini deployment anında görmek için Lighthouse veya WebPageTest yeterlidir. Field data aynı değişimi 4–6 hafta içinde gösterir; o süre zarfında onlarca başka değişken devreye girmiş olabilir. Performans regresyonunu erken yakalamak istiyorsanız CI pipeline'ına lab tabanlı performans bütçeleri entegre etmek mantıklıdır.

İnce ayar ve debug için lab verisi vazgeçilmezdir. Render engeli, JavaScript ayrıştırma süresi, layout shift tetikleyicisi gibi detaylar lab ortamında izole edilir. Field data bunları toplu ve gürültülü biçimde sunar; lab verisi ise saati durdurup her kaynağın tam olarak ne zaman ve ne kadar süreyle yüklendiğini gösterir.

İki veri kaynağını birbirinin rakibi olarak değil, birbirini tamamlayan iki mercek olarak görmek gerekir. Lab verisi bir laboratuvar testi gibidir: kontrollü, hızlı, tekrarlanabilir. Field data ise gerçek dünyadan gelen sinyal — gürültülü, gecikmeli, ama tartışmasız daha temsili.

Lighthouse yeşil, Search Console kırmızı gösterdiğinde bir çelişki yoktur; iki farklı gerçeklik ölçülmektedir. Search Console'daki kırmızı gerçek kullanıcı deneyimini yansıtır ve üzerinde durulması gerekir. Lighthouse ise o sorunu nerede aramanız gerektiğini gösterir. Performans çalışmasında hedef Lighthouse puanı değil, kullanıcı deneyimidir. Bu ayrımı net tutan ekipler optimizasyon enerjisini doğru yere yönlendirir.