Core Web Vitals srozumitelně: LCP, INP a CLS

Core Web Vitals jsou tři čísla, kterými Google měří, jak se váš web chová ke skutečnému návštěvníkovi: LCP do 2,5 sekundy, INP do 200 milisekund, CLS do 0,1. Počítají se z 75. percentilu skutečných návštěv za posledních 28 dní, zvlášť pro mobil a zvlášť pro počítač. Test, který si spustíte na svém notebooku, do hodnocení nevstupuje vůbec.

Tři metriky, tři hranice, jeden percentil

Hranice jsou pevně dané a od roku 2024 se nezměnily. Google výsledky rozděluje do tří pásem: dobré, potřebuje zlepšit, špatné.

Metrika	Co měří	Dobré	Potřebuje zlepšit	Špatné
LCP	vykreslení největšího prvku	do 2,5 s	2,5 až 4,0 s	nad 4,0 s
INP	odezvu na interakci	do 200 ms	200 až 500 ms	nad 500 ms
CLS	poskakování rozvržení	do 0,1	0,1 až 0,25	nad 0,25

Co se pod zkratkami skrývá:

• LCP (Largest Contentful Paint) je čas, za který se vykreslí největší prvek ve viditelné části okna. U článku to bývá úvodní fotka, u produktu hlavní obrázek zboží, u čistě textové stránky nadpis nebo první odstavec.
• INP (Interaction to Next Paint) měří, za jak dlouho stránka po klepnutí, kliknutí nebo stisku klávesy vykreslí odpověď. Nepočítá první interakci, ale prakticky tu nejhorší za celou návštěvu. Od 12. března 2024 nahradilo starší FID, které se dívalo jen na první dotyk a prošel jím skoro každý web. Z nástrojů Chrome zmizelo FID úplně v září 2024.
• CLS (Cumulative Layout Shift) je bezrozměrné číslo. Sečte, kolik obsahu vám během načítání uskočilo pod rukama a jak daleko.

Hodnocení „prošlo“ znamená, že se do dobrého pásma vejdou všechny tři metriky současně. Dvě zelené a jedna oranžová je neúspěch.

Proč vám Lighthouse ukazuje něco jiného než Search Console?

Protože každý měří něco jiného. Lighthouse, tedy i spodní část výsledku v PageSpeed Insights, je laboratorní test: jedno načtení, simulovaná pomalá mobilní síť, simulovaný slabší procesor, prázdná mezipaměť prohlížeče. Výsledkem je skóre 0 až 100, které není Core Web Vitals. Skládá se z pěti metrik s váhami: Total Blocking Time 30 %, LCP 25 %, CLS 25 %, First Contentful Paint 10 %, Speed Index 10 %.

Všimněte si, co v tom seznamu chybí. INP. V laboratoři ho změřit nejde, protože nikdo neklikal, a tak Lighthouse místo něj počítá Total Blocking Time. Slušný náhradník, ale pořád jen náhradník.

Horní blok PageSpeed Insights s nadpisem o datech skutečných uživatelů je něco jiného. To je CrUX, sbírka měření z prohlížečů Chrome od lidí, kteří povolili sdílení statistik. Klouzavé okno 28 dní, aktualizace každý den, data zhruba dva dny zpětně. A právě tahle čísla, ne to zelené kolečko, používají vyhledávací systémy Googlu.

Nejčastější zpráva, kterou od klientů dostávám, zní: „Máme 98 bodů, tak je to v pořádku.“ Bývá to 98 bodů v režimu pro počítač, zatímco mobilní CrUX u téhož webu hlásí LCP 4,1 sekundy. Dívejte se na mobil. Na většině českých webů, které mi projdou rukama, tvoří mobilní návštěvy 60 až 75 %.

Proč váš web v CrUX vůbec není?

Protože na něj nechodí dost lidí. Aby se stránka nebo doména do CrUX dostala, musí mít dost návštěv z Chrome od uživatelů se zapnutým sdílením statistik. Konkrétní hranici Google nikdy nezveřejnil. Podle toho, co vidím u klientů, se pohybuje někde kolem několika set až tisíce návštěv měsíčně na doménu, ale berte to jako odhad, ne jako fakt.

Druhá podmínka: stránka musí být veřejně dostupná a indexovatelná. Kód 200, žádný noindex, žádné heslo. Testovací doména ani zaheslovaná verze webu se do CrUX nedostanou nikdy.

Ještě jedna věc, která lidi plete. Data mohou existovat pro celou doménu, ale ne pro konkrétní adresu. PageSpeed Insights pak ukáže čísla za celý web, i když jste zadali jednu podstránku. Na ladění konkrétní šablony jsou takové údaje k ničemu.

Rodinný penzion s osmi sty návštěvami měsíčně v CrUX nebude. V Search Console uvidí prázdnou sestavu a PageSpeed Insights mu napíše, že data od skutečných uživatelů nejsou k dispozici. Neznamená to, že je web rychlý. Znamená to, že se neměří.

Co s tím dělám v praxi: opravím věci, které jsou zjevně špatně (odezva serveru, neodložené skripty třetích stran, obrázky bez rozměrů), a pak si přiznám, že přesné číslo mít nebudu. Když potřebujete tvrdá data, musíte si měření nasadit sami, třeba knihovnou web-vitals a naměřené hodnoty posílat do analytiky. Jak si postavit vyhodnocování celkově, rozebírám v textu o měření výsledků SEO.

Co reálně zlepší LCP na WordPressu

Pořadí podle toho, kolik to obvykle vydá:

1. Odezva serveru. Doporučená hranice TTFB je 0,8 sekundy, nad 1,8 sekundy je to špatné. Na nejlevnějších sdílených tarifech u Wedosu nebo Forpsi vídám u WordPressu bez cache 900 ms až 2 s. Přechod na lepší tarif s PHP 8.2 a diskem NVMe umí sundat půl sekundy dřív, než sáhnete na jediný obrázek. Novější PHP vám ale nepomůže, pokud web brzdí plugin, který si při každém načtení volá cizí API.
2. Cache stránek. Bez ní se každý požadavek počítá znovu. LiteSpeed Cache je zdarma a na serverech s LiteSpeed odvede skvělou práci, WP Rocket stojí kolem 1 500 Kč ročně za jednu doménu. Rozdíl mezi „žádná cache“ a „jakákoli rozumná cache“ bývá 500 až 1 200 ms na LCP.
3. Přednostní načtení hlavního obrázku. WordPress od verze 6.3 sám přidává fetchpriority="high" prvnímu obrázku, který není odložený a má plochu nad 50 000 pixelů. Funguje to jen tehdy, když je hlavní obrázek opravdu v HTML jako <img>. Pokud ho stavitel stránek vykresluje jako pozadí v CSS nebo ho veze posuvník, WordPress ho nepozná a preload si musíte nastavit ručně.
4. Odložené načítání pryč z horní části stránky. Nejčastější chyba, jakou vidím. Klient v optimalizačním pluginu zaškrtne odložené načítání „na všechno“ a zpomalí přesně ten obrázek, ze kterého se LCP počítá. Zdržení jde do stovek milisekund a spraví ho jedno odškrtnutí. Vypněte odklad pro první jeden až dva obrázky na stránce. Podrobněji to rozebírám v článku o obrázcích a rychlosti webu.
5. Blokující skripty a styly v hlavičce. Souhlas s cookies, chat, mapa, měřicí kódy, čtyři sady písem. Každý synchronní skript v <head> zdrží vykreslení. Co všechno na web tahají cizí služby, jsem rozepsal u skriptů třetích stran.

Na Shoptetu ani Upgates první dva body neovlivníte, o server se stará provozovatel. Zbývají obrázky, doplňky a vlastní kód v šabloně. Bývá toho překvapivě dost.

Co způsobuje poskakování stránky?

Skoro vždycky jedna ze čtyř věcí:

• Obrázky bez rozměrů. Chybí width a height v HTML, prohlížeč nezná poměr stran a po stažení obrázku odsune text dolů. Platí to i pro vložená videa a rámy iframe.
• Lišty vložené dodatečně. Cookie lišta, pruh „doprava zdarma nad 1 500 Kč“, odznak Ověřeno zákazníky, upozornění na výprodej. Skript doběhne o sekundu později, vloží prvek nad obsah a celá stránka se posune. Rezervujte jim místo dopředu, nebo je vykreslujte přes obsah, ne nad ním.
• Reklamní bloky. Sklik i AdSense doručují formáty s proměnlivou výškou. Kontejneru nastavte pevnou minimální výšku podle formátu, který se zobrazuje nejčastěji.
• Písma. Text se nejdřív vykreslí systémovým písmem, pak se přepne na stažené, a protože má jiné rozměry znaků, řádky se přelomí jinam. Pomáhá font-display: swap spolu s dopředným načtením souboru písma a dobře zvoleným náhradním písmem.

Test bez nástrojů: na mobilu načtěte stránku znovu, nechte prst mimo displej a první tři sekundy se jen dívejte. Co uskočí vám, to vidí i Chrome.

INP je skoro vždycky JavaScript

Když hlavní vlákno prohlížeče něco počítá déle než 50 milisekund, mluví se o dlouhé úloze. Po tu dobu nemůže prohlížeč reagovat na klik. Poskládejte za sebe tři takové a jste přes 200 ms.

Typický zdroj na WordPressu: patnáct pluginů, z nichž každý přidá vlastní soubor JavaScriptu, k tomu jQuery, posuvník, filtr produktů, počítadlo košíku a dvě analytiky. Na e-shopech bývá nejhorší filtrování v kategorii, kde se po každém zaškrtnutí překresluje celý výpis zboží.

Druhá věc, kterou lidé podceňují, je hardware. Váš pracovní notebook má několikanásobně rychlejší procesor než čtyřletý Android za čtyři tisíce, na kterém vám návštěvník web otevírá. Co u vás trvá 40 ms, u něj klidně 200. Než začnete něco vypínat, projděte si vztah JavaScriptu a SEO, ať neodstraníte něco, co potřebujete pro indexaci.

Search Console navíc hlásí INP po skupinách podobných adres, ne po jednotlivých stránkách. Opravujete tedy šablonu, ne jednu URL. Když problém vězí v detailu produktu, spraví se s jedním zásahem celá skupina.

Nejvíc pomáhá smazat pluginy, které nepoužíváte, načítat chat a podobné doplňky až po první interakci uživatele a u vlastního kódu rozsekat dlouhé výpočty na menší kousky, aby se mezi nimi prohlížeč nadechl.

Jak moc Core Web Vitals ovlivňují pozice?

Google to říká přímo: Core Web Vitals používají jeho hodnoticí systémy. Vzápětí dodává, že chce ukázat nejrelevantnější obsah, i když je zážitek ze stránky podprůměrný. Tím je řečeno skoro všechno.

Pomalý web s nejlepší odpovědí na dotaz bude nad rychlým webem s horší odpovědí. Mezi pěti weby, které mají podobně dobrý obsah, podobné odkazy a podobnou důvěryhodnost, ale rozhoduje i tohle. O kolik pozic si polepšíte, nikdo veřejně nevyčíslil, a kdo vám takové číslo slíbí, nemá ho odkud vzít.

Silnější argument je jiný. Návštěvník, kterému se stránka načítá čtyři sekundy, odejde dřív, než uvidí cenu. Poskakující rozvržení znamená chybné klepnutí a odchod. Pomalá odezva košíku znamená nedokončenou objednávku. Rychlost prodává i na webech, kam Google skoro nechodí, třeba na přistávacích stránkách pro Sklik nebo na prokliku z Heureky a Zboží.cz.

U Seznamu je situace nejasná. Vlastní veřejné hodnocení rychlosti Seznam nepublikuje a jeho robot se chová jinak než Googlebot. Tvrdit, že Core Web Vitals hýbou pozicemi na Seznamu, by bylo vymýšlení. Podrobnosti k českému vyhledávači najdete v textu o SEO pro Seznam.cz.

Kde začít, když nevíte, co je rozbité

Zjistěte, jestli vůbec máte terénní data. Otevřete PageSpeed Insights, zadejte adresu, přepněte na mobil a podívejte se na horní blok. Je prázdný? Řiďte se laboratorními čísly a zdravým rozumem. Data tam jsou? Opravujte v pořadí LCP, CLS, INP, protože v tomhle pořadí bývá poměr odvedené práce a výsledku nejlepší.

Netestujte jen titulní stranu. Ta bývá vyladěná, zatímco výpis kategorie a detail produktu, kde se rozhoduje o objednávce, na tom bývají výrazně hůř. Vezměte jednu adresu od každé šablony.

Rychlý přehled o tom, co má web technicky rozbité, vám dá bezplatná SEO kontrola webu. Ukáže mimo jiné obrázky bez rozměrů, blokující skripty nebo chybějící hlavičky pro cache, tedy přesně ty věci, které za špatnými čísly stojí. Zbytek technického základu jsem shrnul v přehledu technického SEO.

Časté dotazy

Za jak dlouho se oprava projeví v Search Console?

Počítejte s 28 dny, klidně i o něco déle. CrUX pracuje s klouzavým oknem 28 dní, takže se hodnota po nasazení opravy zlepšuje postupně, jak ze statistiky vypadávají staré návštěvy. První pohyb uvidíte v PageSpeed Insights zhruba do týdne, plný efekt až po čtyřech týdnech.

Stačí mi v PageSpeed Insights 90 bodů?

Nestačí, protože to skóre nejsou Core Web Vitals. Číslo 0 až 100 pochází z laboratorního testu Lighthouse a počítá se z pěti metrik, mezi kterými INP vůbec není. Rozhoduje horní část výsledku s daty od skutečných návštěvníků, kde musíte splnit LCP do 2,5 s, INP do 200 ms a CLS do 0,1.

Musím mít zelené všechny tři metriky?

Pro hodnocení „prošlo“ ano, všechny tři musí být na 75. percentilu v dobrém pásmu současně. Zlepšení má ale smysl i bez zelené: posun LCP ze 4,5 na 3,0 sekundy návštěvník pozná, i když se do limitu 2,5 s ještě nevejdete. Hranice berte jako cíl, ne jako vypínač.