Core Web Vitals: co měří LCP, INP a CLS a jak je zlepšit

Core Web Vitals jsou tři metriky, kterými Google měří skutečný zážitek návštěvníků: rychlost načtení (LCP), odezvu na interakce (INP) a vizuální stabilitu (CLS). Jsou potvrzeným hodnoticím signálem a zároveň nejsrozumitelnějším technickým KPI, jaké web má – tři čísla, tři limity, jasná diagnóza. V tomto průvodci je rozebereme bez vývojářského slangu: co přesně měří, kde najít reálná data a jak opravit nejčastější viníky.

Proč Google měří právě tohle

Google potřebuje doporučovat weby, ze kterých se lidé vracejí spokojení – a frustrace má měřitelné podoby: čekání na obsah, mrtvá tlačítka, uskakující layout. Core Web Vitals tyhle tři frustrace kvantifikují z reálných dat uživatelů Chromu (tzv. CrUX), ne z laboratoře. Hodnotí se 75. percentil: metrika je „zelená”, pokud limit splní tři čtvrtiny reálných návštěv. Do hodnocení vstupují jako součást signálů použitelnosti – nerozhodují samy o pozicích, ale při srovnatelném obsahu rozhodují a červená čísla web táhnou dolů plošně.

Tři metriky v přehledu

Metrika	Co měří	Dobré	Špatné
LCP Largest Contentful Paint	Za jak dlouho se vykreslí největší prvek obsahu (typicky úvodní obrázek či nadpis)	≤ 2,5 s	> 4 s
INP Interaction to Next Paint	Jak rychle stránka zareaguje na kliknutí, klepnutí či psaní (nejhorší interakce návštěvy)	≤ 200 ms	> 500 ms
CLS Cumulative Layout Shift	Jak moc obsah při načítání poskakuje (součet nečekaných posunů layoutu)	≤ 0,1	> 0,25

LCP: rychlost, jak ji vnímá člověk

LCP neměří „načtení stránky” (technicky mlhavý pojem), ale moment, kdy návštěvník vidí hlavní obsah – u většiny webů úvodní obrázek nebo velký nadpis. Nejčastější viníci: těžký, nezoptimalizovaný úvodní obrázek (řešení: WebP, správné rozměry, prioritní načtení – žádný lazy loading nad ohybem!), pomalá odezva serveru (levný hosting, chybějící cache) a render-blokující CSS/JS, které vykreslení zdržují. Rychlá diagnóza: PageSpeed Insights přímo ukáže, který prvek je LCP a co ho zdržuje. Kompletní postup zrychlování ve 12 krocích máme v samostatném návodu na rychlost webu.

INP: metrika, na kterou weby nejčastěji narážejí

INP nahradilo starší FID a je přísnější: měří odezvu všech interakcí během návštěvy a reportuje tu nejhorší. Klepnete na menu a nic se půl vteřiny neděje? To je INP. Viníci: JavaScript – hlavně skripty třetích stran (měření, chaty, personalizace), těžké page buildery a dlouhé úlohy blokující hlavní vlákno. Opravy podle dopadu: vyhodit nepoužívané skripty, zbytek načítat odloženě (defer/async), rozdělit dlouhé úlohy, u WordPressu prověřit pluginy nástrojem typu Query Monitor. INP bývá nejtěžší na opravu, protože viník často „patří marketingu” – další tag, další widget, další chat. Pomůže pravidlo: každý nový skript na webu musí mít vlastníka a důvod – a jednou za kvartál se seznam projde a proškrtá.

CLS: konec poskakujících stránek

CLS trestá moment, kdy chcete kliknout na tlačítko – a ono uskočí, protože se nad ním donačetl banner. Viníci: obrázky a videa bez rozměrů (prohlížeč jim neumí rezervovat místo), reklamy a embedy vkládané nad obsah, webfonty přeskakující ze záložního písma, cookies lišty odsouvající obsah. Opravy: width/height u všech médií, rezervované místo pro reklamní pozice, font-display: swap s podobným záložním fontem, lišty jako overlay místo odsunu. CLS je nejsnazší z trojice – většinou pár zásahů do šablony s okamžitým efektem. Bonus: stabilní layout znatelně snižuje omylné kliky na reklamy a špatná tlačítka.

Laboratoř vs. realita: proč se čísla liší

Klasický zmatek: PageSpeed ukazuje 90, Search Console hlásí červenou. Vysvětlení: laboratorní data (Lighthouse skóre) jsou simulace jedné návštěvy na standardizovaném zařízení – hodí se na diagnostiku; reálná data (CrUX – to, co vidíte v Search Console a horní části PageSpeed) jsou měsíční agregace skutečných návštěvníků – a právě ta Google používá. Řiďte se reálnými daty, laboratoř používejte na hledání příčin. Pozor na dvě pasti: reálná data se aktualizují ~28denním oknem (oprava se projeví se zpožděním) a menší weby je nemusí mít vůbec (málo návštěv v Chromu) – pak platí laboratoř a zdravý rozum: testujte na průměrném telefonu s mobilními daty, ne na výkonném počítači v kanceláři.

Jak číst report v Search Console

Sestava Core Web Vitals ukazuje mobilní a desktopová data zvlášť – mobil je přísnější a důležitější. Kliknutím na problém uvidíte skupiny URL: Google seskupuje podobné stránky (všechny články, všechny produkty…), takže jedna oprava šablony zpravidla vyřeší celou skupinu. Pracovní postup: identifikovat skupinu → diagnostikovat vzorovou URL v PageSpeed → opravit v šabloně → „Ověřit opravu” v konzoli (spustí 28denní sledování). Bez tlačítka ověření se stav také přepíše, jen bez notifikace. Kompletní práci s konzolí popisuje náš návod na Search Console.

Kolik toho Core Web Vitals reálně zmůžou

Upřímná kalibrace očekávání: zelené metriky z desáté pozice první neudělají – obsah a autorita váží víc. Co reálně přinášejí: odstranění brzdy (červená čísla srážejí celý web, zvlášť na mobilu), lepší konverze (rychlý, stabilní web prodává měřitelně líp – to je hlavní byznysový přínos), výhodu v težkých soubojích (při srovnatelné kvalitě rozhodují) a čitelnost pro AI roboty, kteří mají omezenou trpělivost. Správný přístup: dostat metriky do zelené, udržovat je kvartální kontrolou – a neutápět měsíce v honbě za dokonalým skóre, které už nic nepřidá. Rozdíl mezi skóre 85 a 98 návštěvník nepozná – rozdíl mezi červenou a zelenou ano.

Nejčastější viníci podle metriky: tahák na diagnostiku

Červené LCP? V 80 % případů úvodní obrázek (velikost, formát, lazy loading nad ohybem) nebo pomalý server (TTFB nad 0,8 s → cache a hosting). Červené INP? Otevřete PageSpeed → sekce „Minimalizujte práci hlavního vlákna” a podívejte se, čí skripty vedou – vlastní šablona, nebo třetí strany? U WordPressu vypněte na testovacím webu polovinu pluginů a měřte znovu; viník se najde půlením. Červený CLS? Nahrajte si načítání stránky (DevTools → Performance se zaškrtnutým „Screenshots”) a uvidíte přesně, co uskočilo – obvykle obrázek bez rozměrů, banner nebo font. Diagnóza vždy předchází opravě: plošné „zrychlování” bez identifikace viníka je nejdražší možný postup.

Modelový příklad: z červené do zelené za dva týdny

Firemní web na WordPressu, mobilní data: LCP 4,8 s, INP 420 ms, CLS 0,31 – všechno červené. Týden 1: úvodní fotky do WebP se správnými rozměry a prioritním načtením (LCP → 2,9 s), cache plugin s optimalizací CSS (LCP → 2,3 s ✓), rozměry u všech obrázků + rezervované místo pro cookies lištu (CLS → 0,05 ✓). Týden 2: audit skriptů – vyhozený nepoužívaný chat a duplicitní analytika, zbytek defer; heatmapa jen na klíčových stránkách (INP → 180 ms ✓). Celkem ~10 hodin práce, žádný redesign. Za měsíc se zelená čísla propsala do Search Console – a majitel poprvé viděl, že mobilní konverze dohnaly desktop. Přesně v tomhle pořadí (obrázky → cache → CLS → skripty) se vyplatí postupovat téměř vždy.

Core Web Vitals podle typu webu

E-shop: kritické jsou kategorie a produktové stránky – tam se rozhoduje o nákupu; hlídejte CLS u galerie a dostupnosti (donačítané ceny umí rozhodit layout) a INP u filtrování. Obsahový web: LCP úvodních obrázků článků a CLS reklamních pozic; reklamy bez rezervovaného místa jsou nejčastější červený CLS na českém internetu. Firemní web se službami: obvykle nejjednodušší případ – pár šablon, viníkem bývá těžký page builder a slider na homepage; výměna slideru za statický obrázek s CTA zlepší LCP i konverze. Web s formuláři a kalkulačkami: INP je král – každé klepnutí do formuláře se počítá, těžké validační skripty a našeptávače potřebují optimalizaci. Prioritizujte podle stránek, které vydělávají – zelený blog s červenou pokladnou je špatně seřazený projekt – opravujte tam, kde jsou peníze.

Checklist: Core Web Vitals pod kontrolou

• V Search Console vím, které skupiny URL jsou červené/oranžové – mobil především.
• U každé skupiny znám konkrétního viníka z PageSpeed diagnostiky, ne jen skóre.
• Obrázky: WebP, správné rozměry, žádný lazy load nad ohybem, width/height všude.
• Cache a komprese zapnuté; TTFB pod 0,8 s.
• Skripty třetích stran prošly auditem: co není potřeba, je pryč; zbytek defer/async.
• Rezervované místo pro bannery, embedy a lišty – nic neodsouvá obsah.
• Po opravě spuštěno „Ověřit opravu” a v kalendáři kvartální kontrola.

Nejčastější otázky ke Core Web Vitals

Co jsou Core Web Vitals?

Tři metriky, kterými Google měří zážitek návštěvníků z reálných dat: LCP (rychlost vykreslení hlavního obsahu, limit 2,5 s), INP (odezva na interakce, 200 ms) a CLS (vizuální stabilita, 0,1). Hodnotí se 75. percentil skutečných návštěv, mobil a desktop zvlášť. Jsou potvrzenou součástí hodnocení Googlu a najdete je v Search Console.

Kde zjistím Core Web Vitals svého webu?

Dva hlavní zdroje: PageSpeed Insights (zadáte URL, vidíte reálná data nahoře a laboratorní diagnostiku pod nimi) a Search Console → sestava Core Web Vitals (přehled celého webu po skupinách stránek). Řiďte se reálnými daty – laboratorní skóre slouží k hledání příčin, ne k hodnocení. Menší weby reálná data mít nemusí; pak platí laboratoř.

Jak moc Core Web Vitals ovlivňují pozice?

Jsou to podpůrné signály – nerozhodují samy, ale při srovnatelném obsahu rozhodují a červené hodnoty táhnou web dolů plošně, zvlášť na mobilu. Zelené metriky berte jako hygienu: odstraňují brzdu a zlepšují konverze, ale desátou pozici na první nepromění. Investujte do nich tolik, aby byly zelené – a dál už do obsahu.

Co je INP a proč nahradilo FID?

INP (Interaction to Next Paint) měří odezvu stránky na všechny interakce během návštěvy a reportuje nejhorší z nich. Nahradilo FID, které měřilo jen první interakci a bylo příliš shovívavé – většina webů ho plnila automaticky. INP je přísnější a typicky ho kazí JavaScript třetích stran: měřicí kódy, chaty, widgety. Je to dnes nejčastěji červená metrika.

Proč mám v PageSpeed dobré skóre, ale Search Console hlásí problém?

Porovnáváte dvě různé věci: Lighthouse skóre je laboratorní simulace jedné návštěvy, Search Console ukazuje reálná data uživatelů Chromu za ~28 dní. Google hodnotí podle reálných dat. Časté vysvětlení: testujete na rychlém počítači, zatímco návštěvníci chodí z pomalejších mobilů – nebo se oprava do 28denního okna ještě nepropsala.

Za jak dlouho se oprava projeví?

V reálných datech do ~28 dní (klouzavé okno CrUX), v Search Console po spuštění „Ověřit opravu” sledujete průběh přímo v sestavě. Laboratorně si opravu ověříte okamžitě v PageSpeed. Dopad na pozice, pokud byly metriky výrazně červené, přichází v týdnech po zezelenání – společně s dalšími signály, ne jako skokový efekt.

Zvládnu opravy Core Web Vitals bez vývojáře?

Částečně: komprese obrázků, cache plugin, rozměry médií a úklid pluginů zvládnete v administraci – to pokryje většinu LCP a CLS problémů. INP a zásahy do šablony (render-blocking, dlouhé úlohy) už obvykle chtějí vývojáře. Rozumný postup: udělat administrátorské opravy podle našeho návodu na rychlost, změřit, a vývojáře poslat jen na zbytek s konkrétní diagnózou.