Zpět na blog

Core Web Vitals: proč uptime monitoring nestačí

· 6 min čtení

Ve zkratce: Server vám vrací HTTP 200, monitoring říká "UP" - a vy stejně ztrácíte trafic z Google. Core Web Vitals (LCP, INP, CLS) měří reálnou uživatelskou zkušenost. Pomalý web je z pohledu Google "down" stejně jako nedostupný.

Ve zkratce: Server vám vrací HTTP 200, monitoring říká "UP" - a vy stejně ztrácíte trafic z Google. Core Web Vitals (LCP, INP, CLS) měří reálnou uživatelskou zkušenost. Pomalý web je z pohledu Google "down" stejně jako nedostupný.

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ě keyword match 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 loaduje synchronně a blokuje paint
  • Třetí strana (analytics, advertising) blokuje main thread
  • Layout se přeskakuje, jak se loadují elementy

Z perspektivy návštěvníka je web pomalý a nepoužitelný - z perspektivy 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 realný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

  1. Synthetic uptime check - klasický HTTP monitor každou 1-5 min. Detekuje hard downtime, 5xx, expirované certifikáty.
  2. 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).
  3. Visual regression check - screenshot diff. Detekuje když se stránka renderuje úplně jinak než předtím (CSS broken, font fail, JS error).
  4. Real User Monitoring - JS snippet ve stránce zbiera 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é fallback

SEO impact

Google používá CWV jako tie-breaker. Při stejně relevantním obsahu upřednostní rychlejší stránku. V kompetitivních nišich to je 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. Response time monitoring zachytí pomalé endpointy.

Vyzkoušet ePulz.io →

Vyzkoušejte ePulz.io zdarma - 7 dní bez kreditní karty.

Vytvořit účet