Lab Verisi ve Alan Verisi
Lighthouse ve Gerçek Kullanıcı Verisi Neden Farklı Çıkar?
Lighthouse'ta 92 puan göründüğünde Search Console'u açıp Core Web Vitals raporuna bakmak doğal bir reflekstir. Ama orada çok farklı bir tablo sizi karşılar: LCP "İyileştirme gerekiyor" kategorisinde, belki de kırmızıda. İlk tepki genellikle "hangisi doğru?" sorusudur. Yanıt şudur: ikisi de doğrudur, çünkü ikisi farklı şeyleri ölçmektedir.
Bu fark bir hata değil, tasarım gereğidir. Lighthouse belirlenmiş koşullar altında belirli bir sayfanın nasıl yüklendiğini ölçer. CrUX ise son 28 gün içinde o sayfayı ziyaret eden gerçek kullanıcıların deneyimlerini toplar. Biri kontrollü bir deney ortamıdır; diğeri bir nüfus istatistiğidir. İkisinin aynı sonucu vermesi beklenmemelidir.
Sorun bu farkı anlamamaktan kaynaklanır. Optimizasyon kararları yalnızca lab verisine dayandırıldığında gerçek kullanıcıların deneyimi iyileşmeyebilir. Yalnızca alan verisine dayandırıldığında sorunun kaynağı tespit edilemez. Her iki kaynağı doğru bağlamda okumak, performans çalışmasının temel becerisidir.
Lab verisi nedir, Lighthouse neyi ölçer
Lighthouse bir laboratuvar ölçüm aracıdır. Sayfayı yükler, metrik değerlerini kaydeder ve bir puan üretir. Bu süreç her seferinde aynı koşullarda gerçekleşir: sabit bir tarayıcı yapılandırması, önceden tanımlanmış CPU kısıtlaması, sabit bir ağ profili. Sonuç tekrarlanabilir ve karşılaştırılabilirdir; dün aldığınız puanla bugün aldığınız puan aynı koşullar altında elde edilmiştir.
Bu tekrarlanabilirlik bir güçtür. Bir değişiklik yapıp Lighthouse'u tekrar çalıştırdığınızda farkı doğrudan ölçebilirsiniz. A/B karşılaştırması mümkündür; değişkenler kontrol altındadır. Ancak bu kontrol ortamı aynı zamanda lab verisinin sınırını da çizer. Gerçek kullanıcılar kontrollü bir ortamda değil; çeşitli cihazlarda, farklı ağ koşullarında ve değişken kullanıcı davranışlarıyla sayfanıza gelir.
Throttling ve simülasyon: lab ortamının yapay sınırları
Lighthouse varsayılan olarak CPU'yu yaklaşık 4× yavaşlatır ve ağı Slow 4G profiline kısıtlar. Bu değerler sabit biçimde uygulanır; gerçek bir ağ bağlantısı veya gerçek bir cihaz yoktur. Ağ simülasyonu, paket kaybını veya ani gecikme artışlarını modeller ama gerçek bir hücresel bağlantının değişkenliğini yakalayamaz.
Bu simülasyonun pratik sonucu şudur: Lighthouse, orta segment bir Android telefonu zayıf bir ağda kullanmayı temsil etmeye çalışır. Ancak "temsil etmeye çalışmak" ile "gerçekten o koşullarda çalıştırmak" arasında ölçülebilir bir fark vardır. Düşük bellekli cihazlarda JavaScript parse maliyeti simülasyonun öngördüğünden yüksek çıkabilir; ağ değişkenliği gerçek dünyada çok daha geniş bir aralıkta seyreder. Lighthouse skoru bu simülasyonun bir çıktısıdır, gerçek cihaz performansının değil.
Alan verisi nedir, CrUX nasıl çalışır
Chrome User Experience Report (CrUX), Chrome kullanıcılarının gerçek tarama deneyimlerinden toplanan anonim verilerdir. Kullanım istatistiklerini paylaşmayı kabul etmiş Chrome kullanıcılarının gerçek yükleme süreleri, LCP, CLS ve INP değerleri bu veri tabanına akar. Search Console'daki Core Web Vitals raporu bu veriden beslenir.
Alan verisi, her kullanıcı ziyaretinin bir ölçüm noktası olduğu anlamına gelir. Beş yüz farklı cihazdan, farklı ülkelerden, farklı saatlerde gelen beş yüz ziyaret beş yüz ayrı veri noktası üretir. Bu veri noktalarının dağılımı — genellikle 75. yüzdelik dilim baz alınır — asıl değeri oluşturur. Sonuç, o sayfanın tipik kullanıcısının deneyimidir; en iyi koşulların ya da en kötü koşulların değil.
CrUX veri gecikmesi ve 28 günlük kayan pencere
CrUX verisi gerçek zamanlı değildir. Veriler 28 günlük kayan pencere üzerinden toplanır ve genellikle birkaç günlük bir gecikmeyle raporlanır. Bugün yaptığınız bir optimizasyon Search Console'da hemen görünmez. İyileşmenin rapora yansıması için yeterli ziyaret sayısına ulaşması ve 28 günlük pencerenin ilerlemesi gerekir.
Bu gecikme bir yorumlama tuzağı yaratır. Bir performans sorunu bugün çözdüyseniz ve Search Console puanı iki hafta sonra da iyileşmediyse, bu çözümün etkisiz olduğu anlamına gelmez. Eski veri hâlâ pencereye dahil edilmektedir. Öte yandan yavaş bir dönem geçirdiyseniz — sunucu sorunu, dağıtım hatası — bu verinin etkisi bir aydan fazla raporlarınızda görünmeye devam eder. Anlık değişiklikleri değerlendirmek için lab verisi, genel eğilimi izlemek için alan verisi kullanılmalıdır.
Cihaz çeşitliliği ve kullanıcı profili
Lighthouse tek bir sanal cihaz profiliyle çalışır. Gerçek kullanıcılarınız ise yüzlerce farklı cihaz modelinden, farklı tarayıcı versiyonlarından ve farklı donanım kapasitelerinden gelir. Kullanıcı tabanınızın önemli bir kısmı üç dört yaşındaki düşük bellekli cihazlarda geziniyorsa, Lighthouse'un simüle ettiği "orta segment" profil onların deneyimini temsil etmez.
Bu dağılım sektöre göre dramatik biçimde değişir. E-ticaret sitelerinde ziyaretçilerin büyük çoğunluğu telefondan gelirken, B2B yazılım ürünlerinde masaüstü ağırlıklı olabilir. Bir haber sitesinin kullanıcı tabanı coğrafi olarak yavaş ağ bölgelerine yayılmışsa, aynı site güçlü bir bağlantıda mükemmel Lighthouse puanı alırken gerçek kullanıcılarda zayıf alan verisi üretebilir. CrUX bu kullanıcı profilini yansıtır; Lighthouse yansıtmaz.
Ağ koşullarındaki gerçek değişkenlik
Lighthouse'un Slow 4G simülasyonu sabit bir gecikme ve bant genişliği değeri uygular. Gerçek bir hücresel bağlantı ise anlık olarak değişir. Kullanıcı asansörde, kalabalık bir mekânda ya da bina içinde zayıf sinyal bölgesindeyken sayfanıza geldiğinde, ağ koşulları simülasyonun çok ötesine geçer. Paket kaybı, yeniden gönderim gecikmeleri ve bağlantı kopmaları gerçek deneyimi şekillendirir.
TTFB değeri üzerinde bu etki özellikle belirgindir. Bir CDN'den sunulan sayfanın Lighthouse'taki TTFB'si yüksek performanslı, kararlı bir ağ üzerinden ölçülür. Gerçek kullanıcılar ise birden fazla TCP el sıkışması, DNS çözümleme gecikmesi ve değişken yönlendirici koşullarıyla aynı sayfaya ulaşmaya çalışır. Alan verisi bu gerçekliği yakalarken lab verisi onu dışarıda bırakır.
Kullanıcı davranışının metriklere etkisi
Lighthouse sayfayı pasif biçimde yükler; kullanıcı etkileşimi simüle etmez. INP gibi etkileşim metrikleri bu nedenle lab ortamında tam olarak ölçülemez. Bir kullanıcı sayfa yüklenir yüklenmez bir butona basmaya çalışırsa ya da hızlıca kaydırırsa, bu etkileşimlerin ana iş parçacığı üzerindeki etkisi lab ortamına yansımaz.
Benzer biçimde, kullanıcının önceki ziyaretlerden gelen tarayıcı cache durumu da farklılık yaratır. Tarayıcı cache'inin ısındığı tekrarlayan ziyaretlerde gerçek kullanıcılar çok daha hızlı yükleme deneyimi yaşar. Lighthouse varsayılan olarak boş cache ile çalışır ve her testi soğuk başlatır. İlk ziyaret mi tekrarlayan ziyaret mi sorusu, lab verisinin ne kadar temsil edici olduğunu doğrudan etkiler.
Search Console CWV puanının Lighthouse'tan neden ayrıştığı
Search Console'daki Core Web Vitals raporu sayfaları "İyi", "İyileştirme gerekiyor" ve "Zayıf" olarak sınıflandırır. Bu sınıflandırma CrUX verisine dayanır ve 75. yüzdelik dilimi baz alır. Ziyaretçilerinizin yüzde 75'i iyi bir deneyim yaşıyorsa sayfa "İyi" kategorisine girer; yüzde 74'ü iyi yaşıyorsa girmez.
Lighthouse ise 0–100 arası bir puan üretir ve bu puan ağırlıklı ortalamaya dayanır. İki sistem farklı ölçüm yöntemleri, farklı veri kaynakları ve farklı eşik değerleri kullanır. Bir sayfanın Lighthouse puanı 90 olabilir ama Search Console'da "İyileştirme gerekiyor" sınıfında kalabilir; çünkü gerçek kullanıcıların 75. yüzdelik LCP değeri 2,5 saniyelik eşiği aşıyordur. Bu bir tutarsızlık değil, iki ayrı soruya iki ayrı yanıttır.
Laboratuvar verisinin güçlü olduğu durumlar
Lab verisi teşhis için vazgeçilmezdir. Bir sorunu izole etmek, bir değişikliğin etkisini ölçmek, gerileme testleri yapmak — bunların tümü lab ortamında yapılır. CrUX size "LCP kötü" der ama neden kötü olduğunu söylemez. Lighthouse ise LCP'ye katkıda bulunan kaynakları, gecikme nedenlerini ve hangi elementin LCP olduğunu gösterir.
CI/CD hattına entegre performans kontrolleri de lab verisine dayanır. Her dağıtımda Lighthouse çalıştırıp eşik değerlerini kontrol etmek, gerilemeyi erken yakalamanın pratik bir yoludur. Alan verisi bu hızı sunamaz; gerileme CrUX'a yansımadan önce günler geçer. Performans bütçesi uygulamalarının çoğu bu nedenle lab ölçümlerine dayanır.
Alan verisinin güçlü olduğu durumlar
Gerçek kullanıcı deneyimini anlamak için alan verisi tek güvenilir kaynaktır. "Optimizasyonlarımız kullanıcıları gerçekten etkiliyor mu?" sorusunun yanıtı yalnızca alan verisinde bulunur. Lighthouse puanı yükseldi ama kullanıcı şikayetleri devam ediyorsa alan verisine bakmak gerekir. CrUX dağılımı incelendiğinde 75. yüzdelik dilim iyi görünse de dağılımın uzun kuyruğu — en yavaş yüzde 10 — sorunlu bir segment olduğunu ortaya koyabilir.
Alan verisi aynı zamanda SEO açısından da belirleyicidir. Google, arama sıralama değerlendirmelerinde lab verisi değil CrUX kullanır. Search Console'da sayfalarınızın "İyi" eşiğini geçip geçmediği, organik görünürlük açısından doğrudan öneme sahiptir. Bu eşiği aşmak için Lighthouse puanını değil, gerçek kullanıcı metriklerini iyileştirmek gerekir.
İki kaynağı birlikte yorumlama
Lab verisi ve alan verisi birbirinin alternatifi değil, tamamlayıcısıdır. Bir çalışma akışı bu ikisini birbirini besler biçimde kullanmalıdır. Önce alan verisiyle hangi sayfaların ve hangi metriklerin sorunlu olduğu belirlenir. Ardından lab araçlarıyla o sayfalarda sorunun kaynağı teşhis edilir. Çözüm üretilir, lab ortamında test edilir. Dağıtım sonrası alan verisinin değişip değişmediği izlenir.
Bu döngü dışına çıkıldığında ya gerçek kullanıcıları etkilemeyen sorunlar için çalışılır ya da gerçek sorunlar gözden kaçar. LCP gibi bir metriği iyileştirirken hangi kullanıcı segmentinin en çok etkilendiğini bilmek, müdahalenin önceliğini belirler. Bu bilgi alan verisinden gelir; lab verisinden değil.
CrUX verisi olmayan sayfalar
Her sayfa CrUX'ta görünmez. Yeterli ziyaret eşiğine ulaşmamış sayfalar — genellikle aylık birkaç yüz ziyaretin altındakiler — CrUX veri tabanında temsil edilmez ve Search Console raporlarında görünmez. Bu durum özellikle yeni yayınlanan sayfalar ve düşük trafikli içerik kategorileri için geçerlidir.
CrUX yoksa alan verisi de yoktur. Bu durumda yalnızca lab verisiyle çalışmak zorunlu hale gelir. Sayfa düzeyinde CrUX bulunmasa da origin düzeyinde — tüm sitenin ortalaması — veri mevcut olabilir. Search Console origin düzeyi verisini de gösterir. Düşük trafikli sayfalarda lab verisi teşhis için daha kritik bir rol üstlenir; çünkü alternatif yoktur.
Sapmayı yorumlarken dikkat edilmesi gerekenler
Lab ve alan verisi arasındaki sapma her zaman endişe kaynağı değildir. Küçük bir sapma normaldir ve beklenir. Sorun büyük ve açıklanamayan sapmalar ortaya çıktığında başlar. Lighthouse 85 gösterirken Search Console kırmızıysa, bu fark araştırılmayı hak eder.
Araştırmanın başlangıç noktaları şunlar olabilir: ziyaretçi cihaz dağılımı Lighthouse'un varsayımından çok mu farklı; coğrafi dağılım ve CDN kapsama alanı; kullanıcı davranışı ve sayfayla etkileşim örüntüleri; son dönemde gerçek kullanıcı deneyimini etkileyen sunucu ya da altyapı değişiklikleri. Bu soruları sormadan sapmayı "araç hatası" ya da "yanıltıcı veri" olarak görmek, gerçek bir sorunu gözden kaçırmanın en hızlı yoludur.
Performans çalışmasının amacı lab puanını yükseltmek değil, gerçek kullanıcıların deneyimini iyileştirmektir. Lab verisi bu hedefe ulaşmak için bir araçtır; hedefin kendisi değil. Lighthouse skoru yükselirken alan verisi düşüyorsa doğru yönde gittiğinizden söz etmek mümkün değildir; tersi de geçerliyse aynı şey söylenebilir.
İki kaynağı birbirinden bağımsız okumak yanıltır. Lab verisini teşhis için, alan verisini sonuç ölçümü için kullanmak, her iki aracın gücünü yerinde değerlendirmektir. Bu ayrımı içselleştiren bir ekip, optimizasyon kararlarını hem somut verilere hem de gerçek kullanıcı deneyimine dayandırabilir.
Sayfa her test edildiğinde Lighthouse puanı değişebilir; bu normaldir. Ama CrUX birkaç puanlık dalgalanmadan etkilenmez. O dalgalanmaların altındaki gerçek örüntüyü görmek için sabır ve yeterli veri gerekir. İki kaynağı birlikte izlemek, tek başına ne lab verisinin ne de alan verisinin verebileceği bütünlüğü sağlar.