Core Web Vitals: proč uptime monitoring nestačí

Server vrací 200, monitoring říká UP - a vy přesto ztrácíte návštěvnost z Google. Core Web Vitals měří reálnou zkušenost uživatele.

Tři metriky CWV

Google v 2020 zavedl Core Web Vitals jako ranking factor. Od března 2024 je tvoří:

LCP (Largest Contentful Paint) - kdy se zobrazí největší prvek stránky. Dobře: ≤ 2,5 s. Třeba zlepšit: 2,5-4 s. Špatně: > 4 s.
INP (Interaction to Next Paint) - jak rychle stránka reaguje na user interakce (klik, tap). Nahradil FID v březnu 2024. Dobře: ≤ 200 ms. Třeba zlepšit: 200-500 ms. Špatně: > 500 ms.
CLS (Cumulative Layout Shift) - kolik se prvky stránky vizuálně hýbou během načítání. Dobře: ≤ 0,1. Třeba zlepšit: 0,1-0,25. Špatně: > 0,25.

Proč to monitoring nezachytí

Klasický uptime monitor pošle HTTP GET request a měří:

Status kód (200 = OK)
Time to first byte (TTFB)
Volitelně shoda klíčového slova v HTML

Ale nerenderuje stránku v prohlížeči. Nevidí, že:

JavaScript bundle má 3 MB a parsing trvá 4 sekundy
Hero obrázek se načítá synchronně a blokuje paint
Třetí strana (analytics, advertising) blokuje main thread
Layout poskakuje, jak se načítají elementy

Z pohledu návštěvníka je web pomalý a nepoužitelný, ale z pohledu monitoringu je všechno "UP".

Lab vs field data

CWV se měří dvěma způsoby:

Lab data (Lighthouse, PageSpeed Insights, WebPageTest) - kontrolovaný browser, definovaná síť (typicky 4G), konkrétní device. Reprodukovatelné, vhodné na regresní testování po deployích.

Field data / RUM (Chrome User Experience Report, vlastní JS) - sběr dat od reálných návštěvníků v jejich reálných podmínkách. To, co Google používá na ranking. Reflektuje skutečnou variabilitu (3G mobilní klient z vlaku, desktop fiber atd.).

Lab data jsou dobrá reference, field data jsou pravda.

Pozn.: ePulz.io aktuálně CWV metriky neeviduje. Pro jejich měření použijte specializované nástroje (PageSpeed Insights, WebPageTest, Lighthouse CI, případně vlastní RUM JS snippet). Pro vizuální regrese ePulz.io nabízí monitor typu visual, který porovnává screenshoty - to částečně kryje scénáře "stránka se renderuje úplně jinak", ale neměří LCP/INP/CLS.

Praktická monitoring strategie

Synthetic uptime check - klasický HTTP monitor každou 1-5 min. Detekuje hard downtime, 5xx, expirované certifikáty.
CWV měření (mimo ePulz) - Lighthouse CI v deployment pipeline nebo nightly cron jednou denně. Detekuje regresi po nasazení (LCP se zdvihl z 1,8 s na 4,2 s po nasazení nového JS bundle).
Visual regression check - screenshot diff. Detekuje, když se stránka vykreslí úplně jinak než předtím (rozbité CSS, selhání fontu, JS error).
Real User Monitoring - JS snippet ve stránce sbírá CWV od reálných návštěvníků. Sledujete 75th percentile metrik.

Top příčiny špatných CWV

LCP příliš vysoké:

Velké hero obrázky bez priority hint (fetchpriority="high")
Pomalý server / TTFB (CDN cache miss, slow DB query)
Blocking resources v <head> (analytics, fonts bez display=swap)
Web fonts loadované z third-party CDN bez preconnect

INP příliš vysoké:

Velký JS bundle blokující main thread
Synchronní event listenery, které dělají těžkou práci
Pomalé third-party skripty (chat widgets, A/B testing)

CLS příliš vysoké:

Obrázky bez explicitních width a height atributů
Reklamy bez rezervovaného místa
Dynamicky injektované obsahy nad fold
Web fonts s FOUT (Flash of Unstyled Text) bez správného fallbacku

SEO impact

Google používá CWV jako tie-breaker: při stejně relevantním obsahu upřednostní rychlejší stránku. V konkurenčních niších to může být rozhodující.

Praktický dopad:

Web s CWV v "good" rangu má v průměru ~20% nižší bounce rate
Conversion rate stoupá při každém -100 ms LCP
Mobile-first indexing znamená, že Google hodnotí mobilní verzi - testujte tam

Závěr

Uptime monitoring odpovídá na "Je server dosažitelný?". Core Web Vitals odpovídají na "Je web použitelný?". Obě metriky jsou nezávislé a obě potřebujete sledovat. Server může být 100% uptime a web stejně ztrácet traffic kvůli LCP nad 4 sekundy.

Monitoring nad rámec uptime

Visual regression detekuje vizuální změny i když server vrací 200. Monitoring doby odezvy zachytí pomalé endpointy.

Vyzkoušet ePulz.io →