Core Web Vitals prakticky: LCP, INP a CLS v roce 2026
· 10 min čtení
Otevřete si libovolný český článek o Core Web Vitals a je slušná šance, že vám bude tvrdit, jak je důležitá metrika FID. Problém je, že FID už rok a půl neexistuje. Google ji vyřadil 12. března 2024 a nahradil metrikou INP. Kdo dnes měří FID, měří ducha.
Tenhle detail není hnidopišství. Je to spolehlivý test aktuálnosti. Pokud vám někdo v roce 2026 optimalizuje "First Input Delay", pracuje podle zastaralého manuálu. A vy podle něj možná ladíte věci, které už nikdo neměří, zatímco INP, na kterém dnes záleží, propadá.
V tomto článku si projdeme tři metriky, které Google skutečně hodnotí, jejich konkrétní prahy, co každou z nich rozbíjí a jak ji opravit. Bez teoretického balastu.
Co jsou Core Web Vitals a proč ovlivňují pozice
Core Web Vitals jsou tři metriky, kterými Google měří, jak se váš web chová z pohledu reálného návštěvníka. Ne jak rychle se načte na drahém notebooku s optikou, ale jak ho vnímá člověk s průměrným mobilem na LTE.
Každá metrika sleduje jinou část zážitku. Jak rychle se objeví hlavní obsah. Jak svižně web reaguje na kliknutí. A jestli se pod rukama neposouvá layout. Dohromady dávají obrázek toho, jestli je stránka příjemná, nebo frustrující.
Google je používá jako součást hodnocení stránek. Nejsou to nejsilnější faktor, obsah a odkazy váží víc, ale fungují jako rozhodčí u vyrovnaných zápasů. Když se o pozici perou dvě podobně silné stránky, rychlejší a stabilnější vyhrává. U konkurenčních frází to rozhoduje.
Druhý efekt je přímější. Pomalý web ztrácí návštěvníky ještě dřív, než se vůbec zobrazí. Každá vteřina navíc znamená víc lidí, kteří zavřou kartu. Core Web Vitals tedy neřešíte jen kvůli Googlu, ale kvůli konverzím.
INP nahradil FID: proč je FID mrtvý
Do března 2024 se responzivita webu měřila metrikou FID (First Input Delay). Ta sledovala jedinou věc: zpoždění úplně první interakce návštěvníka. První kliknutí, první ťuknutí. A nic víc.
To byl zásadní problém. Uživatel na webu neklikne jednou. Rozbaluje menu, filtruje produkty, přepíná varianty, odesílá formulář. FID z celé té cesty hodnotil jen první krok a zbytek ignoroval. Web tak mohl mít výborné FID a přitom u každé další akce sekat.
INP (Interaction to Next Paint) tuhle mezeru zavírá. Měří odezvu všech interakcí během celé návštěvy a jako výsledek bere tu nejhorší, s odfiltrováním extrémů. Sleduje dobu od kliknutí po okamžik, kdy prohlížeč vykreslí odpověď.
Rozdíl je v praxi obrovský. Weby, které měly bezvadné FID, najednou propadají na INP. Nezhoršily se, jen se poprvé měří to, co uživatel skutečně zažívá. INP je přísnější a poctivější zároveň.
Proto je zmínka o FID tak dobrý indikátor. Kdo o něm v roce 2026 mluví jako o živé metrice, nesledoval poslední velkou změnu Core Web Vitals. A když člověk zaspal tuhle, otázka je, co dalšího mu uteklo.
Tři metriky a jejich prahy
Každá metrika má tři pásma: dobré, potřebuje zlepšení a špatné. Cílem je dostat se do zeleného. Hodnoty vycházejí z reálných uživatelů a Google je posuzuje na 75. percentilu, tedy 75 % návštěv musí být v pásmu "dobré".
| Metrika | Co měří | Dobré | Potřebuje zlepšení | Špatné |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Rychlost načtení hlavního obsahu | do 2,5 s | 2,5 - 4 s | nad 4 s |
| INP (Interaction to Next Paint) | Odezva na interakce | do 200 ms | 200 - 500 ms | nad 500 ms |
| CLS (Cumulative Layout Shift) | Vizuální stabilita layoutu | do 0,1 | 0,1 - 0,25 | nad 0,25 |
Zapamatujte si tři čísla: 2,5 sekundy, 200 milisekund, 0,1. To je celá tabulka, kolem které se točí všechno ostatní. Web, který splní všechny tři prahy na 75. percentilu, prošel.
Důležité je to slovo "všechny". Nestačí zvládnout dvě metriky ze tří. Když propadá jediná, propadá celá stránka. A statisticky nejčastěji propadá právě INP, u kterého na prahu 200 ms selhává skoro polovina webů.
Co rozbíjí LCP a jak ho opravit
LCP měří, za jak dlouho se vykreslí největší prvek nad ohybem. Většinou je to hero obrázek, velký nadpis nebo video. Dokud se tenhle prvek nezobrazí, uživatel kouká na prázdno.
Nejčastější viník je těžký, nezoptimalizovaný obrázek. Fotka v původním rozlišení nahraná přímo z foťáku dokáže zabít LCP sama o sobě. Řešení je předvídatelné: moderní formát jako WebP nebo AVIF, správné rozměry a komprese.
Druhá častá příčina je pomalá odezva serveru. Když samotný HTML dokument doputuje pozdě, prohlížeč nemá s čím začít. Pomáhá kvalitní hosting, cache a CDN, aby obsah cestoval z bližšího místa.
Třetí brzda jsou blokující zdroje. Rozsáhlé CSS a JavaScript, které se musí stáhnout a zpracovat dřív, než se vykreslí obsah. Pomáhá kritické CSS načíst přednostně, zbytek odložit a hero obrázek přednačíst pomocí preload.
Poslední drobnost s velkým dopadem: nenechte hlavní obrázek líně načítat. Lazy loading je skvělý pro obrázky níže na stránce, ale u LCP prvku ho vypněte, jinak si zpomalujete přesně to, co chcete zrychlit.
Co rozbíjí INP a jak ho opravit
INP trápí hlavně JavaScript. Když návštěvník klikne, hlavní vlákno prohlížeče musí zareagovat. Pokud je zrovna zaneprázdněné zpracováním rozsáhlého skriptu, kliknutí čeká ve frontě. Uživatel vidí, že se nic neděje, a klikne znovu.
Typický zdroj potíží jsou předimenzované skripty třetích stran. Chaty, heatmapy, měřicí kódy, widgety. Každý z nich přidává práci hlavnímu vláknu. Projděte si, co na webu opravdu potřebujete, a zbytek odstraňte nebo načtěte odloženě.
Pomáhá dělit dlouhé úlohy na kratší kousky. Když JavaScript blokuje vlákno na stovky milisekund v jednom bloku, prohlížeč nemá kdy odpovědět. Rozdělením práce vznikají mezery, ve kterých stihne reagovat na kliknutí.
E-shopy mají INP obzvlášť rády. Filtrování, řazení, přepínání variant, přidání do košíku. Každá taková akce je interakce, kterou INP měří. Když web u kterékoli z nich sekne, odnese to skóre. Tématu se víc věnuji v článku o SEO pro e-shop.
Řešení tedy vede přes odlehčení a chytré načítání JavaScriptu. Míň kódu, líné načítání toho, co není hned potřeba, a rozdělení náročných výpočtů. INP je metrika, kde se nejvíc vyplatí spolupráce s vývojářem.
Co rozbíjí CLS a jak ho opravit
CLS měří, jak moc se během načítání posouvá obsah. Znáte to: chcete kliknout na odkaz, ale v tu chvíli doskočí obrázek nebo reklama, všechno se posune a vy kliknete jinam. To je layout shift a CLS ho počítá.
Nejčastější příčina jsou obrázky a videa bez uvedených rozměrů. Prohlížeč neví, kolik místa jim vyhradit, takže je nechá naskočit až po stažení a zbytek stránky uskočí. Řešení je triviální: uveďte u médií atributy width a height.
Podobně škodí reklamy a vložené prvky bez rezervovaného místa. Když se banner načte a odsune obsah pod sebou, je to layout shift. Vyhraďte mu prostor předem pomocí pevně dané výšky kontejneru.
Zákeřná bývají webová písma. Stránka se nejdřív vykreslí systémovým fontem a po stažení vlastního písma se text překreslí a přeskládá. Pomáhá font-display: optional nebo swap ve spojení s přednačtením písma.
Poslední případ je dynamicky vkládaný obsah nad už zobrazenou částí. Cookie lišty, notifikace, bannery, které naskočí a stlačí obsah dolů. Buď jim rezervujte místo, nebo je vkládejte tak, aby s existujícím layoutem nehýbaly.
Field data vs lab data: kde měřit správně
Tady dělá spousta lidí zásadní chybu. Otevřou PageSpeed Insights, uvidí zelené skóre 95 a mají pocit, že je hotovo. Jenže tohle číslo je z laboratoře a Google podle něj vaše pozice neposuzuje.
Lab data pocházejí z jedné simulované návštěvy na pevně daném hardwaru se stejným připojením. Jsou skvělá na ladění, protože jsou opakovatelná a ukazují konkrétní problémy. Ale pro hodnocení nemají žádnou váhu.
Field data jsou naopak sbíraná od reálných uživatelů Chromu na jejich zařízeních a sítích. Google je agreguje v Chrome UX Reportu (CrUX) za posledních 28 dní. Přesně tahle data rozhodují o tom, jestli stránka prošla. A často vypadají docela jinak než laboratoř.
Kde měřit? Začněte v Search Console, v přehledu Core Web Vitals. Ukáže field status napříč celým webem seskupený podle šablon, takže hned vidíte, který typ stránek propadá. Pak vezměte jednu reprezentativní URL a hoďte ji do PageSpeed Insights.
V PageSpeed Insights se dívejte na sekci field data nahoře, ne na lab skóre dole. Když field data chybí, stránka nemá dost návštěv a Google si pomáhá daty z celé domény. Search Console plus PageSpeed Insights vám dají kompletní obrázek zdarma.
Priorita: co řešit dřív
Když web propadá ve víc metrikách, nemá smysl řešit všechno najednou. Pořadí je jasné. Otevřete Search Console, podívejte se na mobilní zobrazení a najděte metriku s nejvíc špatnými URL. Tam začněte.
Statisticky bude nejčastěji hořet INP. Na prahu 200 ms propadá skoro polovina webů a bývá to nejtěžší oříšek, protože sahá hluboko do JavaScriptu. Pokud selhává, má obvykle přednost, protože ovlivňuje nejvíc uživatelů.
CLS je naopak nejvděčnější. Bývá nejlevnější na opravu a výsledek přijde rychle. Doplnit rozměry obrázků a vyhradit místo reklamám zvládne často jeden zásah. Když propadá CLS, sáhněte po něm jako první rychlé výhře.
LCP je někde uprostřed. Optimalizace obrázků je snadná, ale pomalý server nebo těžká šablona můžou vyžadovat větší práci. Řešte ho podle toho, jak hluboko problém sahá.
A celé to dělejte na mobilu. Google hodnotí primárně mobilní verzi a právě tam se problémy s výkonem projevují nejvíc. Web, který je v pořádku na desktopu, může na telefonu propadat na všech třech metrikách. Jak celý technický základ zapadá dohromady, shrnuje průvodce technickým SEO.
Tip od SEO specialisty
Nejčastější omyl, který u klientů vidím: honba za skóre 100 v PageSpeed Insights. Lidé týdny ladí laboratorní číslo, které Google k hodnocení nepoužívá, a přitom jim field data v Search Console svítí červeně. Zapomeňte na to zelené kolečko v laboratoři. Otevřete Search Console, najděte šablonu s nejvíc propadlými URL na mobilu a opravte ji. Jeden zásah do šablony se propíše do stovek stránek naráz. To je práce, která se skutečně počítá.