Core Web Vitals vysvětleno pro majitele webů

Core Web Vitals jsou tři měření, kterými Google popisuje, jak stránka působí na skutečného návštěvníka: jak rychle se objeví hlavní obsah, jak rychle stránka reaguje na klepnutí či kliknutí a zda se rozvržení během načítání neposouvá. Jsou součástí signálů uživatelského komfortu stránky (page experience) u Googlu, ale důležitější důvod, proč na nich záleží, je jednodušší. Návštěvníci opouštějí pomalé a poskakující stránky a málokdy vám řeknou proč.

Tento průvodce srozumitelně vysvětluje tři metriky, hranice, které Google zveřejňuje, a jak se rozhodnout, co opravit jako první na běžném webu malé firmy.

Tři metriky v kostce

Metrika	Co měří	Dobré	Špatné
LCP (Largest Contentful Paint)	Čas, než se vykreslí největší viditelný prvek	2,5 sekundy nebo méně	Přes 4 sekundy
INP (Interaction to Next Paint)	Jak dlouho trvá, než stránka vizuálně zareaguje na klepnutí, kliknutí nebo stisk klávesy	200 milisekund nebo méně	Přes 500 milisekund
CLS (Cumulative Layout Shift)	Kolik viditelného obsahu se neočekávaně posouvá	0,1 nebo méně	Přes 0,25

Hodnoty mezi „dobrým“ a „špatným“ spadají do pásma „vyžaduje zlepšení“. Google stránku hodnotí na 75. percentilu skutečných návštěv, což znamená, že tři čtvrtiny vašich návštěvníků by měly zažít komfort na úrovni hranice nebo lepší. Jediný rychlý test na vašem notebooku neprokazuje, že stránka vyhovuje.

Largest Contentful Paint: zobrazuje se stránka?

LCP sleduje největší obrázek, plakát videa nebo blok textu na první obrazovce a zaznamenává, kdy se dokončí jeho vykreslení. Na většině webů je to hlavní obrázek nebo velký nadpis. Pomalé LCP má obvykle jednu ze čtyř příčin: pomalou odezvu serveru, těžký nebo špatně naformátovaný obrázek, CSS či JavaScript blokující vykreslování nebo to, že prohlížeč klíčový obrázek objeví příliš pozdě.

Interaction to Next Paint: reaguje stránka?

INP nahradil starší metriku First Input Delay v březnu 2024. Zatímco First Input Delay sledoval jen první interakci a jen zpoždění před jejím zahájením, INP bere v úvahu interakce během celé návštěvy a hlásí jednu z nejpomalejších, od vstupu do vykreslení dalšího snímku. Stránky, které se rychle načtou, ale působí váznavě při otevření menu nebo stisku tlačítka, mívají problém s JavaScriptem: v hlavním vlákně běží najednou příliš mnoho kódu.

Cumulative Layout Shift: drží stránka na místě?

CLS sčítá neočekávané pohyby viditelných prvků. Zažili jste to, když jste chtěli klepnout na odkaz a nad ním se načetl banner, který odkaz odsunul dolů. Běžnými příčinami jsou obrázky bez atributů šířky a výšky, reklamy a vložené prvky načítané pozdě, fonty, které se vyměňují a mění velikost textu, a cookie lišty vkládané na začátek stránky.

Laboratorní data versus data z reálného provozu

Existují dva druhy měření a jejich pletení způsobuje zmatek.

• Data z reálného provozu pocházejí od skutečných návštěvníků na skutečných zařízeních a sítích. Google je sbírá od uživatelů Chrome a zobrazuje v PageSpeed Insights a Search Console, pokud má váš web dost návštěvnosti. To se počítá při hodnocení.
• Laboratorní data pocházejí ze simulovaného testu, například Lighthouse. Je reprodukovatelný, takže se ideálně hodí k ladění, ale jde o jedno zařízení na jednom připojení.

Malý web nemusí mít data z reálného provozu vůbec. V takovém případě použijte laboratorní testy k hledání problémů a výsledky berte jako vodítko, ne jako verdikt.

Kde začít s opravami

1. Změřte stránky, na kterých záleží. Otestujte úvodní stránku, nejnavštěvovanější vstupní stránku a typický článek či stránku produktu v mobilním profilu. Nepočítejte průměr za celý web.
2. Nejdřív opravte nejhorší metriku. Pokud je LCP špatné a CLS v pořádku, věnujte se LCP.
3. Začněte levnými výhrami. Zkomprimujte a zmenšete hlavní obrázek, nastavte rozměry obrázků, zapněte cachování, zvažte CDN a odstraňte pluginy či skripty, které už nepoužíváte.
4. Po každé změně znovu otestujte. Měňte vždy jednu věc, abyste věděli, co pomohlo.
5. Počkejte, až data z reálného provozu dohoní změny. Čísla z reálného světa se sbírají za klouzavé období, takže zlepšení se plně projeví až za několik týdnů.

Co s tím má společného hosting

Core Web Vitals jsou většinou o tom, jak je stránka postavena, ale hosting nastavuje spodní hranici. Pomalá odezva serveru zpozdí vše, co následuje, a přímo poškozuje LCP. Přeplněné servery, zastaralé verze PHP a chybějící cachování na straně serveru přidávají čas, než prohlížeč obdrží první bajt. Dobrá práce na front-endu nedokáže pomalý back-end plně vyvážit.

Realistické očekávání

Splnit všechny tři metriky je užitečný cíl, ale není to kouzelný přepínač pořadí ve vyhledávání. Mnohem víc stále záleží na relevanci obsahu. Berte Core Web Vitals jako odstraňování tření: slabou stránku do výsledků nevynesou, ale pomalá a poskakující stránka ztěžuje udržet návštěvníky, které už jste získali.

Časté chyby majitelů webů

• Honba za dokonalým skóre Lighthouse. Skóre 100 v laboratorním testu není cíl. Cílem je splnit tři hranice pro skutečné návštěvníky.
• Testování jen na desktopu. Většina hodnocení probíhá na mobilu a mobilní zařízení mají pomalejší procesory a připojení.
• Instalace pluginu pro zrychlení a konec. Pluginy mohou pomoci s cachováním a zpracováním obrázků, ale nezbaví vás 3MB hlavního obrázku ani tuctu marketingových skriptů.
• Přehlížení šablon. Stránky postavené ze stejné šablony obvykle sdílejí stejné problémy, takže oprava šablony opraví mnoho stránek najednou. Search Console proto seskupuje podobné adresy URL.

Veďte jednoduchý záznam toho, co jste změnili, a skóre před a po. Ušetří vám hádání, když se po aktualizaci pluginu něco zhorší.

Rychlé stránky začínají na serveru

Na Zebra Hosting Cloud zahrnuje každý tarif ovládací panel Plesk, ve kterém si můžete zvolit aktuální verze PHP, a na hostovaných webech je dostupné CDN Cloudflare, které servíruje statické soubory blíž návštěvníkům. Dohromady pokrývají serverovou stranu rovnice, takže se můžete soustředit na samotnou stránku. Co jednotlivé tarify nabízejí, zjistíte v přehledu hostingu.