Co dnes Core Web Vitals skutečně měří

Core Web Vitals jsou sada metrik, které hodnotí, jak rychle a stabilně se web načítá a reaguje z pohledu reálného uživatele. Google je používá jako součást hodnocení kvality stránky, přičemž rozhodující nejsou jen technické testy v laboratoři, ale i data z Chrome User Experience Report, tedy z anonymizovaných měření skutečných návštěv. To je zásadní změna: web může v testu Lighthouse vypadat dobře, ale v praxi selhávat kvůli pomalému mobilnímu připojení, přetíženému serveru nebo těžkým skriptům.

Aktuálně se sledují tři hlavní ukazatele: LCP (Largest Contentful Paint), INP (Interaction to Next Paint) a CLS (Cumulative Layout Shift). LCP měří, kdy se zobrazí největší viditelný prvek na stránce, typicky hero obrázek nebo hlavní nadpisová sekce. INP hodnotí, jak rychle web reaguje na interakce uživatele, například kliknutí na menu nebo odeslání formuláře. CLS sleduje vizuální stabilitu, tedy zda se obsah při načítání neposouvá a neskáče.

Jaké jsou nové prahy a proč na nich záleží

Google doporučuje, aby LCP byl do 2,5 sekundy, INP pod 200 milisekund a CLS pod 0,1. Hodnoty mezi doporučeným limitem a horší hranicí jsou považovány za „potřebuje zlepšení“, nad nimi už je stránka v problémové zóně. Z pohledu SEO i UX není důležité jen „být zelený“, ale udržet dobré hodnoty napříč šablonami, zařízeními a typy obsahu.

Nejčastější chybou bývá zaměňování rychlosti serveru za rychlost webu. Server může odpovědět za 100 ms, ale stránka se přesto zobrazí pozdě, protože prohlížeč musí stáhnout a vykreslit velké CSS, JavaScript nebo fonty. V praxi tak o výsledku často rozhoduje front-end, nikoli hosting. U e-shopů a obsahových webů bývá kritický hlavně mobilní výkon, protože většina návštěv přichází z telefonů a na pomalejších sítích.

Pro majitele webu je důležité vědět, že Core Web Vitals nejsou izolovaná metrika. Slabý výkon obvykle zvyšuje míru opuštění stránky, snižuje počet zobrazených produktů nebo článků a zhoršuje konverzní poměr. U nákupního formuláře může i 300ms zpoždění reakce znamenat méně dokončených objednávek, zejména na mobilu.

Jak výkon měřit správně: data z praxe, ne jen z testu

Základní nástroje jsou dnes dobře dostupné. Google Search Console ukáže přehled Core Web Vitals podle skutečných návštěv a rozliší problémové URL. PageSpeed Insights kombinuje laboratorní test a reálná data, takže pomůže odhalit, co je vidět v měření i co se děje v praxi. Lighthouse je vhodný pro rychlou kontrolu při vývoji, ale sám o sobě nestačí. Pro detailní debug je vhodný Chrome DevTools, případně WebPageTest pro simulaci různých sítí a zařízení.

V analytice sledujte i dopad na byznys. V GA4 si připravte segment mobilních uživatelů a porovnejte rychlostní problémy s mírou konverze, mírou opuštění a časem na stránce. U obsahového webu sledujte, zda pomalé načítání neomezuje scroll depth a počet zobrazených stránek na návštěvu. U e-shopu je praktické sledovat vztah mezi výkonem kategorií, produktových detailů a dokončených objednávek.

  • Search Console: identifikuje URL s horším CWV v reálných datech.
  • PageSpeed Insights: ukáže LCP, INP, CLS a konkrétní doporučení.
  • Lighthouse: rychlý audit při vývoji a před nasazením.
  • WebPageTest: vhodný pro testování na 4G, pomalém CPU a různých lokalitách.
  • GA4: propojení výkonu s konverzemi a chováním uživatelů.

Nejčastější příčiny špatného LCP, INP a CLS

Nejhorší LCP obvykle způsobuje velký hero obrázek, video na pozadí, pomalé CSS nebo blokující skripty. Pokud je hlavní vizuální prvek načítán jako pozadí v CSS, prohlížeč jej často prioritizuje hůře než klasický <img>. Praktický krok je použít moderní formáty jako WebP nebo AVIF, správné rozměry a u hlavního obrázku nastavit prioritní načtení. U článků i produktových stránek se vyplatí mít hlavní obsah hned v HTML, ne až po JavaScriptovém renderu.

INP bývá problém tam, kde stránka po načtení spouští příliš mnoho JavaScriptu. Typické jsou cookie lišty, chatovací widgety, mapy, recenze, sledovací skripty a obzvlášť těžké front-end frameworky bez optimalizace. Pokud stránka reaguje pomalu na kliknutí, nestačí jen zrychlit server. Je potřeba zredukovat skripty, odložit jejich načtení, rozdělit bundle a odstranit vše, co není nutné hned po otevření stránky.

CLS vzniká nejčastěji kvůli obrázkům bez definovaných rozměrů, reklamním slotům, dynamickým bannerům, webfontům a pozdně vloženým prvkům. Pokud se uživateli při čtení posune tlačítko nebo text, je to nejen horší UX, ale i signál nekvalitního rozhraní. Z hlediska praxe pomáhá rezervovat prostor pro bannery, používat správné atributy width a height a načítat fonty tak, aby nedocházelo k výraznému přepisu layoutu.

Co má v roce 2025 největší dopad na výkon webu

Nejrychlejší zlepšení obvykle přináší kombinace několika konkrétních zásahů. U WordPressu je to omezení počtu pluginů, výměna těžkého builderu za lehčí šablonu, cache na úrovni serveru a optimalizace obrázků. U webů na Next.js nebo jiném moderním frameworku se vyplatí hlídat množství client-side JavaScriptu, správné dělení komponent a využití server-side renderingu nebo statického generování tam, kde to dává smysl.

Velký rozdíl dělá také infrastruktura. Kvalitní hosting, CDN a správně nastavené cache hlavičky zkracují dobu načítání zejména u opakovaných návštěv. Pro mezinárodní weby je CDN prakticky nutnost, protože snižuje latenci a zlepšuje čas prvního zobrazení. U českých projektů má smysl sledovat i lokalizaci serveru, TTFB a způsob komprese na serveru.

Mezi konkrétní opatření s vysokou návratností patří:

  • komprese a konverze obrázků do WebP nebo AVIF,
  • lazy loading pro neviditelný obsah pod prvním viewportem,
  • odstranění nepoužívaného CSS a JavaScriptu,
  • preload klíčových fontů a hero obrázku,
  • omezování třetích stran, zejména trackerů a widgetů,
  • nastavení cache a CDN pro statický obsah.

U větších webů se vyplatí zavést výkonový budget. Prakticky to znamená určit limity pro velikost stránky, počet requestů, dobu načtení a množství JS na šablonu. Jakmile nový modul nebo kampaň limit překročí, vývojový tým má jasný signál, že úprava je už mimo toleranci.

Jak postupovat při optimalizaci krok za krokem

Smysluplný postup začíná auditem nejdůležitějších šablon: homepage, kategorie, detail produktu, článek a landing page. U každé z nich je vhodné změřit LCP, INP, CLS, počet requestů, velikost stránky a počet třetích stran. Následně se určí, co blokuje první vykreslení a co zatěžuje interakce po načtení.

V praxi se osvědčuje tento pořádek: nejdřív opravit LCP, pak INP a nakonec CLS. Důvod je jednoduchý. Uživatel si nejdřív všimne rychlosti zobrazení hlavního obsahu, potom okamžité reakce na akci a až následně vizuální stability. Pokud web otevře hlavní obsah do 2,5 sekundy, ale tlačítka reagují se zpožděním, stále jde o špatný dojem.

Pro týmy je užitečné zavést pravidelný monitoring. Jednou týdně zkontrolovat Search Console, při každém release udělat Lighthouse audit a jednou měsíčně porovnat výkon s daty v GA4. U větších projektů je vhodné měřit i RUM, tedy real user monitoring, například přes vlastní implementaci nebo nástroje typu SpeedCurve, New Relic či Datadog. Díky tomu lze odhalit, zda se problém týká jen některých zařízení, zemí nebo konkrétních šablon.

Core Web Vitals dnes nejsou jednorázová technická akce, ale průběžná disciplína. Kdo výkon hlídá systematicky, získává výhodu v SEO, lepší uživatelský zážitek a vyšší šanci na konverzi. V době, kdy vyhledávání stále častěji pracuje s reálnou kvalitou webu, se technický výkon stává součástí obsahu i obchodního výsledku.