Core Web Vitals: Co to je a jak je zlepšit

Proč vás Core Web Vitals zajímají

Možná jste na ten pojem narazili v PageSpeed Insights nebo v Search Console a říkali si, co to zase je. Core Web Vitals — zjednodušeně řečeno, Google si od roku 2021 měří, jak rychle se váš web načte, jak svižně reaguje na klikání a jestli při tom všem neposkakuje. Tyhle tři věci reálně ovlivňují, jestli návštěvník zůstane nebo odejde.

Neznamená to, že splnění všech tří vás automaticky dostane na první stránku. Ale při srovnatelném obsahu s konkurencí to může být rozhodující faktor.

Tři metriky, které Google sleduje

LCP — Largest Contentful Paint

Řekněme, že otevřete stránku. LCP měří, za jak dlouho se načte ten největší kus viditelného obsahu — hlavní obrázek, nadpis hero sekce, video. Dokumentace na web.dev/lcp to rozebírá dopodrobna.

Cíl: do 2,5 sekundy. Nad 4 sekundy Google považuje za špatné.

Co s tím:

• Obrázky — WebP formát, správné rozměry, lazy loading pro cokoliv mimo první obrazovku
• Server — Slušný hosting, CDN, caching. Odezva serveru (TTFB) by měla být pod 500 ms — a to hodně hostingů v Česku nesplňuje.
• Blokující zdroje — CSS a JavaScript, které nejsou nutné hned, odložte přes async nebo defer
• Preload — <link rel="preload"> pro hero obrázek a fonty, ať prohlížeč nemusí čekat
• HTTP/2 nebo HTTP/3 — Multiplexing znamená, že se soubory stahují paralelně, ne jeden za druhým

INP — Interaction to Next Paint

Kliknete na tlačítko a nic se neděje. Nebo to trvá tak dlouho, že kliknete znovu. Přesně tohle INP měří — odezvu webu na jakoukoliv interakci (klik, tap, psaní na klávesnici). Detaily na web.dev/inp.

Cíl: do 200 milisekund. Cokoliv nad 500 ms je problém.

INP v březnu 2024 nahradil starší FID (First Input Delay). Rozdíl? FID měřil jen první interakci. INP hodnotí všechny a bere tu nejhorší — takže se neschováte za rychlý první klik, když zbytek webu zamrzá.

Co s tím:

• Kratší JS úlohy — Hlavní vlákno prohlížeče by nemělo být blokované déle než 50 ms. Dlouhé skripty rozkouskujte.
• requestAnimationFrame — Pro vizuální změny místo přímého hrabání se v DOM
• Debounce/throttle — Na scroll, resize a input události. Jinak prohlížeč nestíhá.
• Web Workers — Náročné výpočty přesuňte do vedlejšího vlákna
• Menší DOM — Méně uzlů = rychlejší renderování. Doporučení je pod 1 500 elementů — spousta webů má klidně 5 000.

CLS — Cumulative Layout Shift

Čtete článek, najednou se stránka posune a vy kliknete na reklamu místo odkazu. To je přesně to, co CLS postihuje — neočekávané posuny prvků při načítání. Dokumentace: web.dev/cls.

Cíl: do 0,1. Vypadá to jako malé číslo, ale stačí jeden nepodchycený obrázek bez rozměrů a máte problém.

Co s tím:

• Rozměry u obrázků — Vždycky uvádějte width a height nebo aspect-ratio. Bez toho prohlížeč neví, kolik místa rezervovat.
• Místo pro reklamy — Placeholder s min-height, aby reklama při načtení neodstrčila obsah dolů
• Nic nad existující obsah — Bannery a notifikace vkládejte pod nebo místo obsahu, ne nad něj
• Fonty — font-display: swap a preload. Jinak se text přerendruje, až dorazí webový font, a všechno poskočí.
• Animace — Jenom transform a opacity. Tahle dvě vlastnosti nespouštějí re-layout.

Kde to změřit

Laboratorní data (simulace)

• Lighthouse — Máte ho přímo v Chrome (F12 → záložka Lighthouse). Simuluje pomalejší zařízení a připojení.
• PageSpeed Insights — Google nástroj, který kombinuje simulaci i reálná data
• Web Vitals Extension — Chromové rozšíření, které ukazuje metriky v reálném čase při procházení webu

Reálná data (od skutečných návštěvníků)

• Chrome UX Report (CrUX) — Anonymizovaná data od uživatelů Chrome za posledních 28 dní
• Google Search Console — Sekce „Core Web Vitals" ukazuje stav z pohledu reálného provozu
• PageSpeed Insights — Horní část stránky — ale jen pokud máte dostatek návštěvníků v CrUX datech

Pozor: Google pro hodnocení v Search Console používá reálná data (75. percentil). Lighthouse vám pomůže najít problémy, ale výsledné skóre závisí na tom, co zažívají skuteční návštěvníci.

Na co si dát pozor u českých webů

Z auditů, které přes SEO Radar prošly, vidím pár opakujících se vzorců:

1. Neoptimalizované fotky — Plné rozlišení z fotoaparátu, žádná komprese, chybí WebP. Obrázek 4 MB na homepage není rarita.
2. Pluginy na WordPress — Každý přidává vlastní JS a CSS. Web s 30 pluginy načítá klidně 3 MB JavaScriptu.
3. Pomalý hosting — Sdílené hostingy s TTFB přes 1 000 ms. Server odpoví za sekundu, a to ještě nic nerendroval.
4. Skripty třetích stran — Chat widget, Facebook pixel, analytika, reklamy. Každý zpomaluje INP, protože se pere o hlavní vlákno.
5. Obrázky bez rozměrů — Klasický CLS problém. Stránka „skáče" při načítání a uživatel kliká jinam, než chtěl.

Kontrola v SEO Radaru

V auditu měříme TTFB vašeho serveru a porovnáváme LCP, INP a CLS s reálnými daty z Chrome UX Report — tedy s tím, co doopravdy zažívají vaši návštěvníci za posledních 28 dní, ne se simulací v laboratoři. Když pro váš web CrUX data nemá (u menších webů se to stává), naskočí náhradní odhady: render-blocking zdroje, odhadované FCP a riziko posunu layoutu.

Tip: Vyzkoušejte si bezplatný SEO audit a podívejte se, jak rychlý je váš web ve skutečnosti.