Co jsou Core Web Vitals a jak zrychlit web

Foto: Pixabay

Core Web Vitals jsou tři metriky, kterými Google měří skutečnou zkušenost návštěvníka se stránkou: jak rychle se načte hlavní obsah (LCP), jak svižně web reaguje na kliknutí a psaní (INP) a jak moc se obsah vizuálně poskakuje během načítání (CLS). Jsou součástí signálů kvality stránky ve vyhledávání a zároveň přímo ovlivňují, kolik lidí na webu zůstane a kolik z nich udělá objednávku. V tomhle návodu si projdeme, co jednotlivé metriky znamenají, jaké hodnoty jsou dobré, jak si je změřit a co konkrétně udělat pro jejich zlepšení — zvlášť na WordPressu.

Co jsou Core Web Vitals a proč na nich záleží

Core Web Vitals (česky se ujal termín „základní webové ukazatele“) jsou podmnožinou širšího hodnocení Page Experience od Googlu. Google je zavedl proto, aby měl objektivní, měřitelný způsob, jak posoudit, jestli je stránka pro člověka příjemná na používání. Nejde o umělé číslo z laboratoře, ale o data od skutečných návštěvníků Chromu — tzv. field data ze sady Chrome User Experience Report (CrUX).

Praktický dopad je dvojí. Za prvé jsou Core Web Vitals jedním z hodnotících signálů — při jinak srovnatelném obsahu může rychlejší a stabilnější web získat výhodu. Za druhé, a to je často důležitější, pomalý web ztrácí konverze. Každá vteřina navíc při načítání zvyšuje míru okamžitého opuštění. U e-shopu se to promítne přímo do tržeb, u služeb do počtu poptávek.

LCP – Largest Contentful Paint (jak rychle se načte obsah)

LCP měří, za jak dlouho se vykreslí největší viditelný prvek v první viewportu — obvykle hlavní obrázek, video plakát nebo velký blok textu. Je to nejlepší náhrada za pocit „už to vidím a můžu číst“. Prahové hodnoty jsou jasné: do 2,5 sekundy je to dobré, mezi 2,5 a 4 sekundami potřebuje web zlepšit a nad 4 sekundy je špatné.

Nejčastější brzdy LCP jsou pomalá odezva serveru, blokující CSS a JavaScript, neoptimalizované obrázky a fonty načítané se zpožděním. Na WordpPressu bývá viníkem chybějící cache, těžká šablona nebo hero obrázek nahraný v plném rozlišení.

INP – Interaction to Next Paint (jak svižně web reaguje)

INP nahradilo v březnu 2024 dřívější metriku FID a měří odezvu na interakce po celou dobu návštěvy — kliknutí, ťuknutí, stisk klávesy. Sleduje, jak dlouho trvá, než se po akci uživatele vizuálně něco stane. Dobrá hodnota je do 200 milisekund, do 500 ms je prostor ke zlepšení a nad 500 ms je odezva pomalá.

Za špatné INP může skoro vždy JavaScript, který příliš dlouho blokuje hlavní vlákno prohlížeče. Typicky nadbytečné pluginy, těžké slidery, chatovací widgety, špatně napsané skripty třetích stran nebo měřicí kódy. Uživatel klikne, ale prohlížeč je zaneprázdněný a nestíhá reagovat.

CLS – Cumulative Layout Shift (vizuální stabilita)

CLS měří, jak moc obsah během načítání „poskakuje“. Znáte to: chcete kliknout na odkaz, ale nad ním se doplní obrázek nebo reklama a tlačítko vám uteče. CLS tyto neočekávané posuny sčítá. Dobrá hodnota je do 0,1, do 0,25 je hraniční a nad 0,25 je špatná.

Nejčastější příčiny jsou obrázky a videa bez uvedených rozměrů, reklamy a embedy bez rezervovaného místa, dynamicky vkládaný obsah nad stávajícím a fonty, které při načtení překreslí text. Řešení je většinou technicky jednoduché — jen se na něj zapomíná.

Jak si Core Web Vitals změřit

Měřit můžete dvěma typy nástrojů a je důležité chápat rozdíl mezi nimi. Terénní data (field data) pocházejí od reálných návštěvníků a jsou to hodnoty, které Google skutečně používá. Laboratorní data (lab data) simulují načtení v kontrolovaném prostředí a hodí se k ladění, ale nemusí odpovídat realitě.

• PageSpeed Insights — zdarma, ukazuje field i lab data pro konkrétní URL a dává konkrétní doporučení.
• Google Search Console — sekce Core Web Vitals ukazuje stav celého webu po skupinách URL, ideální pro monitoring v čase.
• Lighthouse (v Chrome DevTools) — laboratorní audit přímo v prohlížeči, dobrý pro ladění během vývoje.
• Chrome DevTools, záložka Performance — pro detailní hledání, co konkrétně blokuje hlavní vlákno.

Praktické pravidlo: pro rozhodování, jestli je problém, se dívejte na field data ze Search Console a PageSpeed Insights. Pro hledání příčiny a testování oprav používejte laboratorní nástroje.

Laboratorní vs. terénní data: proč se liší

Často se stane, že PageSpeed Insights ukáže v laboratorní části špatné skóre, ale field data jsou v pořádku — nebo naopak. Není to chyba. Laboratorní test běží na simulovaném pomalejším zařízení a připojení, zatímco field data jsou průměr přes vaše skutečné návštěvníky za posledních 28 dní. Když má web hodně uživatelů na rychlých zařízeních, reálná zkušenost může být lepší než laboratorní odhad.

Rozhodovat byste se měli podle field dat, protože ta odpovídají tomu, co hodnotí Google. Laboratorní skóre berte jako diagnostický nástroj, ne jako cíl sám o sobě. Honit se za stovkou bodů v Lighthouse nemá smysl, pokud reální návštěvníci mají web rychlý.

Jak zlepšit LCP

• Nasaďte kvalitní cache (na WordPressu např. stránková cache) — nejrychlejší způsob, jak srazit odezvu serveru.
• Hlavní hero obrázek servírujte v moderním formátu (WebP/AVIF) a ve správné velikosti, ne v plném rozlišení.
• Přednačtěte klíčové zdroje (preload) — hlavní obrázek a font viditelný nad ohybem.
• Odstraňte blokující CSS a JS z kritické cesty — kritické styly inline, zbytek odložit.
• Zvažte kvalitnější hosting nebo CDN, pokud je pomalá už samotná odpověď serveru.

Jak zlepšit INP

• Zredukujte počet a velikost skriptů — každý plugin, který přidává JavaScript, je potenciální brzda.
• Odložte načítání skriptů, které nejsou potřeba hned (defer, async, lazy load pro widgety).
• Rozdělte dlouhé úlohy JavaScriptu na menší kousky, aby prohlížeč stíhal reagovat mezi nimi.
• Skripty třetích stran (chat, heatmapy, reklamy) načítejte až po interakci nebo se zpožděním.
• Pravidelně revidujte instalované pluginy — nejlepší optimalizace je odstranit, co nepoužíváte.

Jak zlepšit CLS

• U všech obrázků a videí uvádějte atributy width a height (nebo aspect-ratio v CSS).
• Reklamám, embedům a iframům rezervujte místo předem, aby po načtení nic neposkočilo.
• Fonty načítejte s font-display: swap a přednačtěte hlavní font, ať text nepřeskakuje.
• Nový obsah (bannery, notifikace) vkládejte pod stávající obsah, ne nad něj.

Časté příčiny pomalého webu na WordPressu

WordPress sám o sobě pomalý není — pomalé bývá to, co se na něj naskládá. V praxi za problémy s Core Web Vitals nejčastěji stojí přehlcení pluginy, kdy každý přidá vlastní CSS a JavaScript na všechny stránky, i tam, kde není potřeba. Dalším viníkem je těžká univerzální šablona nabitá funkcemi, které web nevyužívá.

Řešení má obvykle tři patra: cache (výrazně sníží odezvu serveru), optimalizace obrázků (konverze do WebP a lazy loading) a slučování a odkládání skriptů. Teprve když tohle nestačí, má smysl řešit hosting nebo výměnu šablony. Pořadí je důležité — nejlevnější a nejrychlejší zásahy dělejte první.

Vliv na SEO a byznys: co je mýtus a co ne

Kolem Core Web Vitals koluje spousta polopravd. Mýtus číslo jedna: „Když nemám stovku bodů, propadnu se ve výsledcích.“ Není to tak. Core Web Vitals jsou jen jedním z mnoha signálů a obsah a relevance jsou důležitější. Rychlý web s tenkým obsahem neporazí pomalejší web s vynikajícím obsahem.

Co ale platí: mezi dvěma srovnatelnými stránkami může rychlost rozhodnout a špatné Core Web Vitals reálně snižují konverze bez ohledu na pozice. Proto se na ně díváme nejen jako na SEO faktor, ale hlavně jako na věc uživatelské zkušenosti a tržeb. Dobré vitals jsou hygiena, ne kouzelná hůlka.

Checklist rychlého webu

• Zapnutá a fungující cache (ověřeno, ne jen nainstalovaná).
• Obrázky ve WebP/AVIF, správně zmenšené, s lazy loadingem mimo první viewport.
• Hero obrázek a hlavní font přednačtené (preload).
• Minimum pluginů, žádné duplicitní funkce, skripty třetích stran odložené.
• Obrázky a embedy mají rozměry, nic během načítání neposkakuje.
• Pravidelná kontrola v Search Console (sekce Core Web Vitals) po každé větší změně.

Kde technická optimalizace končí

Core Web Vitals jsou skvělý ukazatel technického zdraví, ale samy o sobě z webu neudělají zdroj poptávek. Rychlý web bez dobré struktury, obsahu a klíčových slov nezačne získávat návštěvnost jen proto, že se rychle načte. Technická optimalizace je základ, na kterém teprve staví obsahová a linkbuildingová práce.

Pokud si nejste jistí, jestli je váš web brzděn technikou, obsahem, nebo obojím, vyplatí se začít auditem, který se podívá na všechny vrstvy najednou. Více o tom, co takový rozbor obsahuje, najdete v článku o tom, co obsahuje SEO audit, a proč je optimalizace webu důležitá. Pro hloubkovou technickou kontrolu se hodí i crawler Screaming Frog.

Modelový příklad: jak vypadá zrychlení v praxi

Vezměme si typický firemní web na WordPressu, který přišel na kontrolu s LCP kolem 4,2 sekundy, INP přes 300 ms a CLS 0,18 — tedy všechny tři metriky v červeném pásmu. Diagnóza byla učebnicová: žádná stránková cache, hero fotka nahraná v rozlišení 4000 pixelů na šířku, čtrnáct aktivních pluginů (z toho tři dělaly totéž) a chatovací widget načítaný hned při startu.

Postup oprav šel od nejlevnějšího k nejnáročnějšímu. Nejdřív se zapnula cache, což samo srazilo odezvu serveru a stáhlo LCP pod tři sekundy. Pak se hero obrázek převedl do WebP a zmenšil na reálnou zobrazovanou velikost — LCP kleslo pod 2,5 sekundy. Odstranění dvou duplicitních pluginů a odložení chatu až po první interakci zlepšilo INP pod 200 ms. Doplnění rozměrů k obrázkům a rezervace místa pro widget srazily CLS pod 0,1. Celé to zabralo jedno odpoledne a všechny tři metriky se dostaly do zeleného pásma.

Poučení z příkladu je jednoduché: největší zlepšení obvykle přinesou první, nejjednodušší kroky. Cache a optimalizace obrázků vyřeší většinu problémů s LCP, úklid pluginů většinu problémů s INP a rozměry u médií většinu problémů s CLS. Teprve pak má smysl řešit složitější věci jako kritickou cestu vykreslování.

Nejčastější chyby při optimalizaci

• Instalace „optimalizačního“ pluginu bez pochopení, co dělá — často se navzájem tlučou a web zpomalí ještě víc.
• Optimalizace jen podle laboratorního skóre, aniž byste sledovali field data reálných návštěvníků.
• Zapnutí agresivní minifikace a slučování skriptů, které rozbije funkčnost webu, a nikdo si toho týdny nevšimne.
• Testování jen na desktopu, přestože většina návštěvníků i hodnocení Googlu jde přes mobil.
• Jednorázová optimalizace bez monitoringu — po pár měsících a několika nových pluginech je web zase pomalý.

Nejzákeřnější chyba je poslední: Core Web Vitals nejsou jednorázový úkol, ale průběžná disciplína. Každý nový plugin, každá nová sekce webu a každá reklama jsou příležitostí, jak metriky zase zhoršit. Proto se vyplatí po každé větší změně web znovu proměřit a jednou za čas udělat pořádnou revizi.

Nejčastější dotazy o Core Web Vitals

Jsou Core Web Vitals důležitější než obsah?

Ne. Obsah a jeho relevance vůči tomu, co lidé hledají, jsou pro pozice ve vyhledávání zásadnější. Core Web Vitals fungují spíš jako rozhodovací faktor mezi jinak srovnatelnými stránkami a jako věc uživatelské zkušenosti. Nejlepší strategie je mít kvalitní obsah na technicky zdravém webu.

Jak často se Core Web Vitals aktualizují?

Field data v Search Console i PageSpeed Insights vycházejí z klouzavého okna posledních 28 dní. To znamená, že když nasadíte opravu, projeví se v datech postupně během několika týdnů, ne okamžitě. Buďte proto trpěliví a nekontrolujte výsledky každý den.

Musím mít v PageSpeed Insights 100 bodů?

Nemusíte a je to spíš kontraproduktivní cíl. Skóre v PageSpeed Insights je laboratorní odhad, ne to, co hodnotí Google. Důležité je, aby vaše field data byla v zeleném pásmu. Honba za stovkou bodů často vede k zbytečně složitým zásahům bez reálného přínosu.

Co je INP a proč nahradilo FID?

INP (Interaction to Next Paint) měří odezvu webu na interakce po celou dobu návštěvy, zatímco starší FID hodnotil jen první interakci. INP je proto přesnější obraz toho, jak svižně web reaguje. Google metriku oficiálně nahradil v březnu 2024.

Zlepší cache moje Core Web Vitals?

Ve většině případů výrazně ano, hlavně u metriky LCP. Cache sníží dobu, za kterou server odpoví, což je jeden z hlavních faktorů rychlosti načítání. Na WordPressu je zapnutí kvalitní cache obvykle první a nejúčinnější krok. Sama o sobě ale nevyřeší problémy s JavaScriptem (INP) ani s poskakujícím obsahem (CLS).

Jak Core Web Vitals souvisí s mobilní verzí?

Velmi úzce. Google hodnotí primárně mobilní verzi webu (mobile-first indexing) a Core Web Vitals se sledují zvlášť pro mobil a desktop. Mobilní zařízení bývají pomalejší a na horším připojení, takže právě na mobilu se problémy projeví nejvíc. Optimalizaci proto vždy ověřujte hlavně na telefonu.

Zvládnu optimalizaci Core Web Vitals sám?

Základní kroky jako zapnutí cache, optimalizace obrázků a úklid pluginů zvládne i poučený majitel webu. U hlubších problémů s JavaScriptem, kritickou cestou vykreslování nebo úpravami šablony se ale obvykle vyplatí odborník, protože zásahy mohou web rozbít. Rozumný postup je začít od jednoduchých věcí a složitější přenechat specialistovi.