Core Web Vitals: LCP, INP a CLS

Modul 4: Rychlost, mobilní zařízení a https · Doba čtení: 13 minut

Cíl lekce: Po této lekci dokážete vysvětlit tři Core Web Vitals a jejich hraniční hodnoty, popsat rozdíl mezi daty z terénu a daty z laboratoře, přečíst měření v PageSpeed Insights, řešit nejčastější příčiny špatného výsledku a reálně odhadnout, jakou váhu má rychlost ve výsledcích vyhledávání.

Klíčové pojmy: Core Web Vitals, LCP (Largest Contentful Paint), INP (Interaction to Next Paint), CLS (Cumulative Layout Shift), 75. percentil, data z terénu (CrUX), data z laboratoře (Lighthouse), PageSpeed Insights, přehled Core Web Vitals v Search Console, TTFB, komprese, width a height u obrázků, loading="lazy", uživatelský dojem ze stránky (page experience)

Rychlost ve třech číslech

„Je můj web rychlý?“ je vágní otázka. Google a tvůrci prohlížeče Chrome z ní udělali tři měřitelné otázky, Core Web Vitals:

Několik věcí, kterým je dobré správně porozumět:

• LCP měří okamžik, kdy se objeví největší viditelný prvek. Obvykle je to velká fotka nahoře (tzv. „hero“) nebo velký blok textu. U Bloemenatelier Lotte je to fotografie květinové vazby na domovské stránce.
• INP sleduje všechna kliknutí, klepnutí a stisky kláves během návštěvy a hlásí (téměř) nejpomalejší reakci. INP 12. března 2024 nahradila starší metriku FID (First Input Delay), která sledovala jen první kliknutí a jen čekání před jeho zpracováním. Pokud v nějakém starém článku narazíte na FID, je to zastaralé.
• CLS není čas, ale skóre bez jednotky. Zvyšuje se, když se věci posouvají, zatímco čtete: chcete klepnout na tlačítko a v tu chvíli se nad ním objeví banner, takže klepnete na něco jiného.

75. percentil

Stránka Core Web Vitals „splňuje“, pokud 75 procent návštěv dosáhne dobrého výsledku u všech tří metrik, měřeno zvlášť pro mobilní zařízení a pro počítače. Tomu se říká 75. percentil. Znamená to, že se nepočítá Váš vlastní rychlý počítač na optickém připojení, ale zkušenost většiny návštěvníků, včetně těch se starším telefonem na 4G.

Data z terénu a data z laboratoře

Existují dva druhy měření a často dávají odlišná čísla.

• Data z terénu pocházejí od skutečných návštěvníků. Chrome (u uživatelů, kteří to povolí) anonymně sbírá, jak rychlé stránky byly, do přehledu Chrome User Experience Report (CrUX). PageSpeed Insights zobrazuje data z terénu za posledních 28 dní. Přehled Core Web Vitals v Search Console používá stejný zdroj. Má-li Vaše stránka příliš málo návštěvníků, PageSpeed Insights zobrazí čísla celého webu (tzv. „origin“), a pokud jich má málo i ten, data z terénu nejsou k dispozici.
• Data z laboratoře pocházejí ze simulovaného testu v nástroji Lighthouse: jedno načtení na napodobeném průměrném telefonu a připojení. Lighthouse nedokáže změřit INP (nikdo neklikne), a proto uvádí jiná čísla, například Total Blocking Time, která jsou pro INP alespoň vodítkem.

Pro hodnocení jsou rozhodující data z terénu. Data z laboratoře se hodí k hledání příčin a k tomu, abyste po úpravě hned viděli, zda pomohla, bez čekání 28 dní.

Jakou to má váhu?

Tady se hodně přehání. Co o tom říká sám Google v dokumentaci o uživatelském dojmu ze stránky:

• „Core Web Vitals are used by our ranking systems“: tedy se započítávají.
• Neexistuje žádný samostatný „signál uživatelského dojmu ze stránky“. Další součásti dobrého dojmu (https, žádná vtíravá vyskakovací okna, použitelnost na mobilu) Vám podle Googlu přímo k vyšší pozici nepomohou, ale web díky nim bude příjemnější.
• „Google Search always seeks to show the most relevant content, even if the page experience is sub-par.“ Pomalá stránka s nejlepší odpovědí tedy klidně může být nahoře.
• Dosahovat dokonalého skóre jen kvůli SEO podle Googlu „nemusí být nejlepší využití Vašeho času“.

Závěr: snažte se být v zelené, nebo alespoň v oranžové oblasti, hlavně proto, že návštěvníci z pomalé nebo poskakující stránky odcházejí. Honit se v Lighthouse z 90 na 100 bodů přinese ve výsledcích vyhledávání jen málo.

Příčiny, které můžete řešit sami

Pomalá první odpověď (TTFB)

Vše začíná okamžikem, kdy dorazí první bajt HTML, tzv. Time to First Byte. TTFB sama o sobě není Core Web Vital, ale pomalá TTFB téměř znemožňuje dobrou LCP. web.dev uvádí jako orientační hodnotu: dobré je 0,8 sekundy nebo méně, špatné je více než 1,8 sekundy. Příčiny podle web.dev: málo výkonu u hostingu, chybějící cache (každá stránka se sestavuje znovu, typicky u WordPressu bez pluginu pro cache), přesměrování (lekce 4.1) a vzdálený server bez CDN.

Patří sem i komprese: server by měl HTML, CSS a JavaScript posílat zabalené pomocí gzip nebo Brotli. Poznáte to podle hlavičky Content-Encoding: gzip nebo br. Téměř každý hosting to dělá standardně, ale chybné nastavení nebo starý server ji může vypnout.

Obrázky

Obrázky jsou nejčastější příčinou špatné LCP a CLS:

1. Příliš velké. Fotka široká 4.000 pixelů s 5 MB pro rámeček o šířce 800 pixelů. Zmenšete ji před nahráním a použijte moderní formát, například WebP nebo AVIF.

2. Chybí šířka a výška. Bez width a height prohlížeč neví, kolik místa obrázek potřebuje, a text pod ním poskočí, jakmile se obrázek načte. web.dev doporučuje uvádět width a height u každého <img>:

   <img src="bloemstuk.webp" width="800" height="600" alt="Bruidsboeket met witte rozen">

3. Líné načítání nejdůležitější fotky. loading="lazy" načte obrázek až ve chvíli, kdy se dostane do zorného pole. To je v pořádku pro fotky níže na stránce, ale web.dev říká jasně: obrázky, které jsou vidět hned po otevření, a zejména obrázek LCP, nenačítejte líně. Jinak prohlížeč otálí právě s fotkou, která určuje Vaši LCP.

Poskakující obsah a pomalé reakce

Další příčiny CLS podle web.dev: písma, která při načítání mění velikost, reklamy a vložené widgety, které se samy zvětšují, a obsah, který se později vloží nad stávající obsah (například cookie lišta, která stránku odsune dolů, místo aby ležela přes ni). Špatná INP je téměř vždy způsobena přílišným množstvím JavaScriptu: těžkými šablonami, slidery, chatovacími widgety a sledovacími skripty třetích stran. Na každý plugin nebo vloženou službu se dívejte kriticky; méně je tu opravdu více.

V praxi: měření v PageSpeed Insights

Přejděte na pagespeed.web.dev, zadejte adresu své domovské stránky a klikněte na Analyzovat (Analyze). Dostanete dvě karty, pro mobilní zařízení a pro počítače (Mobile a Desktop). Nahoře je hodnocení Core Web Vitals na základě dat z terénu, pokud jsou k dispozici. Pod ním je test Lighthouse se skóre a seznamem „Diagnostika“ s konkrétními body, například o obrázcích, které jsou větší, než je třeba, nebo o obrázku LCP, který se načítá líně (přesné názvy se s novými verzemi Lighthouse mění). Začněte u mobilní verze: tam bývá výsledek obvykle horší a Google se dívá nejprve na mobilní verzi (lekce 4.2).

Máte-li svůj web v Search Console (modul 2), podívejte se také do části Experience, Core Web Vitals. Tam uvidíte skupiny podobných stránek s jejich stavem, i pro stránky, které jste sami netestovali.

Web vytvořený v AI Builder nastavuje šířku a výšku u obrázků se známou velikostí, první fotku stránky načítá okamžitě a s prioritou (fetchpriority="high"), ostatní líně, a při publikování vytváří z velkých fotek variantu širokou 800 pixelů. Ve WordPressu nejvíce pomůže plugin pro cache a zmenšení obrázků; kurz WordPressu se tomu podrobněji věnuje v modulu 6. U jiných nástrojů pro tvorbu webů a hostingových firem to funguje podobně: tlačítka se liší, příčiny jsou stejné.

Shrnutí

• Core Web Vitals jsou LCP (dobré do 2,5 s), INP (dobré do 200 ms, od března 2024 místo FID) a CLS (dobré do 0,1), měřené na 75. percentilu pro každý typ zařízení.
• O hodnocení rozhodují data z terénu (CrUX, 28 dní); data z laboratoře (Lighthouse) pomáhají najít příčiny.
• Google Core Web Vitals při řazení používá, ale relevance má přednost: dokonalé skóre není cílem samo o sobě.
• Největší přínos: rychlá odpověď serveru s cache a kompresí, malé obrázky s width a height, nejdůležitější fotku nenačítat líně, méně JavaScriptu třetích stran.

Kvíz

Úkol

Úkol A4.3: Rychlá odpověď a lehké obrázky. Zadejte adresu stránky. Program třikrát změří čas do prvního bajtu (TTFB) z našeho serveru a vezme prostřední hodnotu, zkontroluje, zda se HTML posílá komprimované (gzip, Brotli nebo zstd), spočítá obrázky bez width a height a ověří, že se nejdůležitější obrázek nahoře nenačítá s loading="lazy". Pozor: jde o měření z jednoho místa, ne o měření Vašich návštěvníků. Nemáte vlastní web? Použijte www.wikipedia.org.

Úkol D4.3: Vaše Core Web Vitals. Spusťte PageSpeed Insights na své domovské stránce a na jedné další důležité stránce, nejprve pro mobilní zařízení. U každé stránky si zapište: zda jsou k dispozici data z terénu (pro stránku, nebo pro celý web), hodnoty LCP, INP a CLS z dat z terénu, skóre Lighthouse a prvek, který Lighthouse označí jako prvek LCP. Vyberte jedno zlepšení, které podle Vás přinese nejvíce, a vysvětlete proč.

Další čtení

• web.dev, Web Vitals: https://web.dev/articles/vitals
• web.dev, Largest Contentful Paint (LCP): https://web.dev/articles/lcp
• web.dev, Interaction to Next Paint (INP): https://web.dev/articles/inp
• web.dev, Cumulative Layout Shift (CLS): https://web.dev/articles/cls
• web.dev, Time to First Byte (TTFB): https://web.dev/articles/ttfb
• web.dev, Browser-level image lazy loading: https://web.dev/articles/browser-level-image-lazy-loading
• Google Search Central, Understanding page experience in Google Search results: https://developers.google.com/search/docs/appearance/page-experience
• PageSpeed Insights, About PageSpeed Insights: https://developers.google.com/speed/docs/insights/v5/about
• Nápověda Search Console, přehled Core Web Vitals: https://support.google.com/webmasters/answer/9205520