Core Web Vitals: uptime izleme neden yetmez

Kısaca: Sunucu HTTP 200 dönüyor, izleme "UP" diyor - ve siz yine de Google'dan trafik kaybediyorsunuz. Core Web Vitals (LCP, INP, CLS) gerçek kullanıcı deneyimini ölçer. Yavaş bir web Google'ın perspektifinden "down"dır, tıpkı erişilemez gibi.

Kısaca: Sunucu HTTP 200 dönüyor, izleme "UP" diyor - ve siz yine de Google'dan trafik kaybediyorsunuz. Core Web Vitals (LCP, INP, CLS) gerçek kullanıcı deneyimini ölçer. Yavaş bir web Google'ın perspektifinden "down"dır, tıpkı erişilemez gibi.

Üç CWV metriği

Google 2020'de Core Web Vitals'ı ranking faktörü olarak tanıttı. Mart 2024'ten itibaren şunlardan oluşur:

LCP (Largest Contentful Paint) - sayfanın en büyük öğesinin ne zaman göründüğü. İyi: ≤ 2,5 sn. İyileştirilmeli: 2,5-4 sn. Kötü: > 4 sn.
INP (Interaction to Next Paint) - sayfanın kullanıcı etkileşimlerine (tıklama, tap) ne kadar hızlı tepki verdiği. Mart 2024'te FID'i değiştirdi. İyi: ≤ 200 ms. İyileştirilmeli: 200-500 ms. Kötü: > 500 ms.
CLS (Cumulative Layout Shift) - sayfa öğelerinin yükleme sırasında görsel olarak ne kadar hareket ettiği. İyi: ≤ 0,1. İyileştirilmeli: 0,1-0,25. Kötü: > 0,25.

İzleme bunu neden yakalamaz

Klasik uptime monitor HTTP GET isteği gönderir ve ölçer:

Status kodu (200 = OK)
Time to first byte (TTFB)
İsteğe bağlı HTML'de keyword match

Ama sayfayı tarayıcıda render etmez. Şunları görmez:

JavaScript bundle 3 MB ve parsing 4 saniye sürüyor
Hero görüntüsü senkron yükleniyor ve paint'i bloke ediyor
Üçüncü taraf (analytics, reklam) main thread'i bloke ediyor
Öğeler yüklenirken layout zıplıyor

Ziyaretçi perspektifinden web yavaş ve kullanılamaz - izleme perspektifinden her şey "UP".

Lab vs field data

CWV iki şekilde ölçülür:

Lab data (Lighthouse, PageSpeed Insights, WebPageTest) - kontrollü tarayıcı, tanımlı ağ (tipik 4G), belirli cihaz. Tekrarlanabilir, deploy sonrası regresyon testlerine uygun.

Field data / RUM (Chrome User Experience Report, özel JS) - gerçek ziyaretçilerden gerçek koşullarında veri toplama. Google'ın ranking için kullandığı. Gerçek değişkenliği yansıtır (trenden 3G mobile istemci, desktop fiber vb.).

Lab data iyi bir referans, field data gerçektir.

Not: ePulz.io şu anda CWV metriklerini takip etmemektedir. Bunları ölçmek için özel araçlar kullanın (PageSpeed Insights, WebPageTest, Lighthouse CI veya kendi RUM JS snippet'iniz). Görsel regresyonlar için ePulz.io, screenshot'ları karşılaştıran visual türünde bir monitör sunar - bu kısmen "sayfa tamamen farklı render oluyor" senaryolarını kapsar, ancak LCP/INP/CLS'yi ölçmez.

Pratik izleme stratejisi

Synthetic uptime check - klasik HTTP monitor her 1-5 dk. Hard downtime, 5xx, süresi dolmuş sertifikaları algılar.
CWV ölçümü (ePulz dışında) - Deployment pipeline'da Lighthouse CI veya gecelik cron veya headless Chrome günde bir kez. Dağıtım sonrası regresyonu algılar (yeni bir JS bundle deploy'undan sonra LCP 1,8 sn'den 4,2 sn'ye yükseldi).
Visual regression check - screenshot diff. Sayfanın öncekinden tamamen farklı render edildiğini algılar (CSS bozuk, font fail, JS error).
Real User Monitoring - sayfadaki JS snippet'i gerçek ziyaretçilerden CWV toplar. Metriklerin 75. persentilini izlersiniz.

Kötü CWV'nin başlıca nedenleri

LCP çok yüksek:

Priority hint olmadan büyük hero görüntüleri (fetchpriority="high")
Yavaş sunucu / TTFB (CDN cache miss, yavaş DB sorgusu)
<head>'de blocking resources (analytics, display=swap olmadan fontlar)
Preconnect olmadan üçüncü taraf CDN'den yüklenen web fontları

INP çok yüksek:

Main thread'i bloke eden büyük JS bundle
Ağır iş yapan senkron event listener'lar
Yavaş üçüncü taraf scriptleri (chat widget'ları, A/B testing)

CLS çok yüksek:

Açık width ve height öznitelikleri olmadan görüntüler
Rezerve alan olmadan reklamlar
Fold üstünde dinamik olarak enjekte edilen içerikler
Doğru fallback olmadan FOUT'lu (Flash of Unstyled Text) web fontları

SEO etkisi

Google CWV'yi tie-breaker olarak kullanır. Eşit derecede ilgili içerikte daha hızlı sayfayı tercih eder. Rekabetçi nişlerde belirleyicidir.

Pratik etki:

CWV "good" aralığında olan bir site ortalama ~%20 daha düşük bounce rate'e sahip
Her -100 ms LCP ile conversion rate yükselir
Mobile-first indexing, Google'ın mobil sürümü değerlendirdiği anlamına gelir - orada test edin

Sonuç

Uptime izleme "Sunucuya erişilebilir mi?" sorusunu yanıtlar. Core Web Vitals "Web kullanılabilir mi?" sorusunu yanıtlar. Her iki metrik bağımsızdır ve her ikisini de izlemeniz gerekir. Sunucu %100 uptime'a sahip olabilir ve web yine de 4 saniyenin üzerinde LCP yüzünden trafik kaybedebilir.

Uptime'ın ötesinde izleme

Visual regression sunucu 200 dönse bile görsel değişiklikleri algılar. Response time izleme yavaş endpoint'leri yakalar.

ePulz.io'yu dene →