CrUX ve RUM ile Core Web Vitals İzleme: Saha Verisini Takip Etmek

Core Web Vitals’ı bir kez düzeltip bırakırsanız birkaç hafta içinde geri gelir. Yeni bir eklenti, büyütülmüş bir hero görseli ya da etiket yöneticisine eklenen bir pazarlama betiği kazanımı sessizce siler. Kimse fark etmez. Ta ki Search Console raporu kırmızıya dönene kadar. Bu rehber, iyileştirmeyi kalıcı kılan ölçüm düzenini anlatır: Chrome UX Report (CrUX) kaynaklarını doğru okumak, web-vitals kütüphanesiyle kendi gerçek kullanıcı ölçümünüzü (RUM) kurmak, sayfa gruplarına göre raporlamak ve gerilemeyi kullanıcılar hissetmeden yakalamak.

Lab verisi ile saha verisi farkı

Lighthouse ve PageSpeed Insights’ın “Performans” bölümü laboratuvar verisidir: tanımlı bir cihaz ve ağ profilinde, tek bir sayfa yüklemesi. Tekrarlanabilir olduğu için hata ayıklamaya ve geliştirme sırasında karşılaştırmaya uygundur. Saha verisi ise gerçek kullanıcıların farklı cihaz, ağ, önbellek durumu ve davranışla yaşadığı deneyimdir.

Özellik	Laboratuvar	Saha (CrUX/RUM)
Koşullar	Sabit cihaz ve ağ	Gerçek kullanıcı dağılımı
INP	Yükleme denetiminde ölçülmez, TBT vekil metrik; timespan kaydında etkileşimle ölçülebilir	Gerçek etkileşimlerden ölçülür
CLS	Yalnız yükleme sırasında	Sayfa ömrü boyunca
Tekrarlanabilirlik	Yüksek	Dağılım olarak okunur
Kullanım	Teşhis, CI kontrolü	Durum değerlendirmesi, izleme

Arama sonuçlarında kullanılan sayfa deneyimi değerlendirmesi saha verisine dayanır. İzleme düzeninin merkezine saha verisini koyun; laboratuvar testlerini “neden” sorusunu cevaplamak için kullanın. Lab teşhis eder. Saha hüküm verir. Metriklerin ne ölçtüğü ve nasıl iyileştirildiği LCP, INP ve CLS ile web sitesi hızlandırma yazısında; burada odak ölçümün kendisi.

CrUX veri kaynakları ve sınırları

CrUX, kullanım istatistiği paylaşımına izin vermiş Chrome kullanıcılarından toplanan, herkese açık bir veri setidir. Aynı veri farklı arayüzlerden farklı ayrıntı ve zaman çözünürlüğüyle sunulur:

Kaynak	Ayrıntı	Zaman	Uygun kullanım
PageSpeed Insights	URL ve kaynak (origin)	Son 28 gün	Tekil sayfa kontrolü
CrUX API	URL ve origin, cihaz türüne göre	Son 28 gün, günlük güncellenir	Otomatik günlük takip
CrUX History API	URL ve origin	Haftalık dönemler halinde geçmiş	Eğilim grafiği
BigQuery veri seti	Yalnız origin	Aylık	Uzun dönem, rakip karşılaştırması
Search Console raporu	Benzer URL grupları	Son 28 gün	Şablon bazlı sorun tespiti

Bu verinin sınırlarını bilmeden yorum yapmayın:

• Uygunluk eşiği: Bir URL veya origin yalnız yeterli trafik varsa ve herkese açıksa CrUX’ta yer alır. Düşük trafikli hizmet sayfalarında çoğunlukla yalnız origin düzeyi veri bulunur.
• Kitle: Yalnız Chrome’un masaüstü ve Android sürümleri; iOS’taki Chrome ve diğer tarayıcılar dahil değildir.
• Gecikme: 28 günlük kayan pencere nedeniyle bir değişikliğin etkisi kademeli yansır; dünkü yayının etkisi bugün görünmez.
• Kök neden yok: CrUX hangi öğenin LCP olduğunu ya da hangi etkileşimin yavaş olduğunu söylemez.

CrUX API ile günlük takip için tek bir istek yeterlidir:

curl -s "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=$CRUX_API_KEY" \
  -H 'Content-Type: application/json' \
  -d '{
        "origin": "https://www.example.com",
        "formFactor": "PHONE",
        "metrics": ["largest_contentful_paint",
                    "interaction_to_next_paint",
                    "cumulative_layout_shift"]
      }'

Yanıtta her metrik için iyi/geliştirilmeli/kötü kovalarının oranları (histogram) ve percentiles.p75 değeri döner. origin yerine url verdiğinizde sayfa düzeyinde sorgularsınız. Veri yoksa API 404 döndürür; bu bir hata değil, “CrUX’ta yeterli veri yok” demektir. Bu çağrıyı her gün bir zamanlanmış görevle çalıştırıp sonucu saklamak, CrUX’un geçmişini kendi elinizde tutmanın en ucuz yoludur.

75. yüzdelik ve değerlendirme mantığı

Core Web Vitals değerlendirmesi ortalamaya değil, 75. yüzdeliğe (p75) bakar: sayfa yüklemelerinin dörtte üçü eşiğin altındaysa metrik “iyi” sayılır. Ortalama, birkaç çok yavaş ziyaretle bozulabilir ya da büyük bir kitlenin kötü deneyimini gizleyebilir; p75 ikisi arasında dengeli bir ölçüdür. Eşikler web.dev üzerinde tanımlıdır:

Metrik	İyi	Geliştirilmeli	Kötü
LCP	≤ 2,5 s	2,5–4,0 s	> 4,0 s
INP	≤ 200 ms	200–500 ms	> 500 ms
CLS	≤ 0,1	0,1–0,25	> 0,25

Değerlendirme mobil ve masaüstü için ayrı yapılır. Bir sayfanın “geçmesi” için üç metriğin p75 değeri de iyi aralıkta olmalıdır. Kendi RUM verinizi raporlarken aynı mantığı kullanın: aynı yüzdelik, aynı cihaz ayrımı, benzer zaman penceresi. Aksi halde iç raporunuz ile Search Console farklı hikâye anlatır ve toplantı, hangi rakamın doğru olduğunu tartışmakla geçer.

web-vitals ile kendi RUM ölçümünü kurmak

Google’ın açık kaynak web-vitals kütüphanesi metrikleri CrUX ile aynı tanımlarla tarayıcıda ölçer ve küçük boyutludur. Temel kurulum:

import { onCLS, onINP, onLCP, onTTFB } from 'web-vitals';

function send(metric) {
  const body = JSON.stringify({
    name: metric.name,          // LCP, INP, CLS, TTFB
    value: metric.value,
    rating: metric.rating,      // good | needs-improvement | poor
    id: metric.id,              // sayfa yüklemesi başına tekil
    navType: metric.navigationType,
    page: document.body.dataset.template || 'diger',
    path: location.pathname
  });
  (navigator.sendBeacon && navigator.sendBeacon('/rum', body)) ||
    fetch('/rum', { body, method: 'POST', keepalive: true });
}

onCLS(send);
onINP(send);
onLCP(send);
onTTFB(send);

Kurulumda en sık takıldığımız noktalar şunlar:

• Raporlama zamanı: CLS ve INP sayfa ömrü boyunca değişir; kütüphane nihai değeri genellikle sayfa gizlendiğinde gönderir. sendBeacon veya keepalive bu yüzden gereklidir. Düz fetch kullanılırsa sekme kapanırken veri kaybolur.
• Tekilleştirme: Aynı metrik bir sayfa yüklemesinde birden çok kez raporlanabilir. Sunucuda id + name için en son değeri saklayın.
• Sayfa grubu: Örnekte şablon adı body üzerindeki bir data-template özniteliğinden okunuyor. URL’den gruplama yerine şablonun kendisini işaretlemek daha güvenilirdir; URL yapısı değiştiğinde rapor bozulmaz.
• Teşhis verisi: Kütüphanenin web-vitals/attribution derlemesi, LCP öğesi ve INP’ye yol açan etkileşim hedefi gibi kök neden bilgisini ekler. Alan adları sürümler arasında değişebildiği için kullandığınız sürümün README’sini esas alın. Yavaş etkileşimlerin çözümlenmesi INP sorunlarını bulma ve düzeltme yazısında.
• Tarayıcı desteği: LCP ve INP’nin dayandığı tarayıcı API’lerinin desteği tarayıcıdan tarayıcıya değişir; desteklenmeyen tarayıcıda ilgili metrik hiç raporlanmaz. Raporda tarayıcı ailesini ayrı bir boyut olarak tutun.
• Gizlilik: Ölçüm verisini kişisel veri içermeyecek şekilde tasarlayın; IP adresini saklamayın, sorgu dizelerini (location.search) göndermeyin. Çerez onayı politikanızın ölçüm betiğini nasıl sınıflandırdığını netleştirin.

Ölçüm betiği de sayfaya yük ekler. Ayrı bir analitik paketine gömmek yerine mevcut paketle birleştirin ve JavaScript bütçesi içinde değerlendirin.

Sayfa grubu bazlı raporlama

Tüm sitenin tek bir p75 değeri, sorunun nerede olduğunu söylemez. Kurumsal bir web sitesinde ana sayfa, hizmet sayfaları, blog yazıları ve form sayfaları farklı şablon, farklı görsel ve farklı betiklerle çalışır. Raporu en az şu boyutlarla kırın: sayfa grubu, cihaz türü (mobil/masaüstü), metrik. Toplanan ham veriden p75 hesabına örnek (PostgreSQL):

SELECT page_group,
       device,
       name AS metric,
       percentile_cont(0.75) WITHIN GROUP (ORDER BY value) AS p75,
       count(*) AS samples
FROM rum_metrics
WHERE received_at >= now() - interval '28 days'
GROUP BY page_group, device, name
HAVING count(*) >= 200
ORDER BY page_group, device, name;

HAVING satırındaki alt sınır örnek bir değerdir; amacı, birkaç ziyaretlik grupların yüzdelik değerinin raporda “kesin” gibi görünmesini engellemektir. Kendi trafiğinize göre ayarlayın ve rapora örnek sayısını mutlaka yazın. Örnek sayısı olmayan p75 yanıltır.

Gerileme tespiti ve alarm

İzlemenin amacı geriye dönük rapor değil, gerilemeyi CrUX’a yansımadan yakalamaktır. İşleyen bir düzen üç parçadan oluşur:

1. Taban çizgisi: Her sayfa grubu ve cihaz için son 28 günün p75 değeri.
2. Kısa pencere: Son 3–7 günün p75 değeri. Kısa pencere, kayan pencereden çok daha hızlı tepki verir.
3. Kural: Kısa pencere değeri eşik sınırını (ör. LCP 2,5 s) aşarsa veya taban çizgisine göre belirlediğiniz bir paydan fazla kötüleşirse, ve yeterli örnek varsa uyarı üret.

Uyarıyı anlamlı kılan şey bağlamdır. Yayın (deploy), eklenti güncellemesi ve etiket yöneticisi değişikliklerini zaman damgasıyla aynı panoya işleyin; gerilemenin hangi değişiklikten sonra başladığı çoğu zaman tek bakışta görülür. Değişiklik kaydı yoksa kök neden araması günler sürer. Laboratuvar tarafında CI sürecine Lighthouse CI gibi bir kontrol eklemek, gerilemeyi yayından önce yakalamanın tamamlayıcı yoludur.

İzleme kontrol listesi

• CrUX API ile origin ve önemli URL’ler için günlük kayıt alınıyor.
• web-vitals ile LCP, INP, CLS ve TTFB toplanıyor; id ile tekilleştiriliyor.
• Raporlar sayfa grubu ve cihaz türüne göre p75 ve örnek sayısıyla sunuluyor.
• Kısa pencere/taban çizgisi karşılaştırmasıyla uyarı üretiliyor.
• Yayın ve yapılandırma değişiklikleri panoda işaretleniyor.
• Search Console Core Web Vitals raporu ayda bir gözden geçiriliyor.

Saha ölçümü, uptime ve hata izlemeyle aynı operasyon düzenine bağlandığında işe yarar. Biz bu düzeni web izleme ve uptime monitoring ile web performansı ve Core Web Vitals çalışmalarında aynı panoda kuruyoruz.

Sık sorulan sorular

Lighthouse skorum yüksek ama Search Console’da sayfalar kötü görünüyor, neden?

Lighthouse tek bir cihaz ve ağ profilinde laboratuvar ölçümü yapar; Search Console ise gerçek kullanıcıların son 28 günlük saha verisini 75. yüzdelikte değerlendirir. Yavaş cihazlar, zayıf mobil bağlantılar, çerez onayı ve gerçek etkileşimler laboratuvarda görünmez. Esas alınacak olan saha verisidir.

Sitem CrUX’ta görünmüyor, Core Web Vitals’ı nasıl ölçerim?

CrUX yalnız yeterli trafiğe sahip, herkese açık sayfa ve kaynakları içerir. Veri yoksa web-vitals kütüphanesiyle kendi RUM ölçümünüzü kurmak tek güvenilir saha verisi yoludur. Laboratuvar testleri yön gösterir ama saha verisinin yerini tutmaz.

RUM verisi ile CrUX değerleri neden birebir tutmuyor?

Kapsam farklıdır: CrUX yalnız ölçüme izin vermiş Chrome kullanıcılarını içerir, RUM ise metrikleri destekleyen tüm tarayıcılardan ve onay politikanıza bağlı olarak farklı bir kitleden veri toplar. Zaman penceresi ve örnekleme de farklı olabilir. Önemli olan iki kaynağın aynı yönde hareket etmesidir.

Origin düzeyinde değerler iyiyken tek tek sayfalar kötü olabilir mi?

Evet. Origin değeri sitedeki tüm sayfa yüklemelerinden hesaplanır ve trafiği yüksek sayfalar sonucu belirler. Az ziyaret alan bir hizmet veya form sayfası kötü olsa bile origin p75 değeri iyi görünebilir. CrUX’ta URL düzeyi veri yoksa bu sayfaları görmenin tek yolu sayfa grubu bazlı RUM raporudur.