Core Web Vitals srozumitelně: LCP, INP a CLS jednoduše

Core Web Vitals nejsou osobnostní test pro váš web

Core Web Vitals se často berou jako tajemná výsledková tabulka. Stránka dostane červené číslo, někdo pošle screenshot do Slack a tým se začne hádat o JavaScript frameworky.

To není zvlášť užitečné.

Lepší způsob, jak o Core Web Vitals přemýšlet, je jednodušší: jsou to tři měření toho, zda stránka působí použitelně pro skutečného člověka na skutečném zařízení. Nezachycují každý aspekt výkonu, přístupnosti nebo kvality. Zachycují ale tři běžné zdroje frustrace:

• Hlavní obsah se zobrazuje příliš dlouho.
• Stránka reaguje pomalu, když se uživatel pokusí něco udělat.
• Rozvržení poskakuje, zatímco uživatel čte nebo klepe.

To jsou tři Core Web Vitals: LCP, INP a CLS.

Google je používá jako součást signálů page experience, ale SEO pohled není ten nejlepší důvod, proč se o ně zajímat. Lepším důvodem je, že pomalé, poskakující a nereagující stránky plýtvají časem uživatelů. Také mívají horší konverze, horší podporu a hůře stárnou.

Tři metriky jednou větou

Než půjdeme do detailů, tady je verze jednoduchou angličtinou:

• LCP, neboli Largest Contentful Paint, měří, jak dlouho trvá načtení hlavního viditelného obsahu.
• INP, neboli Interaction to Next Paint, měří, jak rychle stránka reaguje na uživatelské interakce během návštěvy.
• CLS, neboli Cumulative Layout Shift, měří, jak moc se stránka neočekávaně posouvá.

Obvyklé prahové hodnoty jsou:

| Metrika | Dobré | Potřebuje zlepšení | Špatné | |---|---:|---:|---:| | LCP | 2,5 s nebo rychlejší | 2,5 s–4,0 s | Více než 4,0 s | | INP | 200 ms nebo rychlejší | 200 ms–500 ms | Více než 500 ms | | CLS | 0,1 nebo méně | 0,1–0,25 | Více než 0,25 |

Tato čísla se obvykle vyhodnocují na 75. percentilu reálných návštěv uživatelů. Na tom záleží. Nesnažíte se dosáhnout jednoho dokonalého laboratorního běhu. Snažíte se zajistit dobrou zkušenost pro většinu uživatelů, včetně lidí na pomalejších telefonech a méně stabilních sítích.

Pokud se díváte na automatizovaný report a nevíte, kde začít, pomůže oddělit diagnostiku od paniky. Máme samostatný průvodce tím, jak číst Lighthouse report bez paniky, který tento postup popisuje podrobněji.

LCP: kdy stránka působí jako načtená?

Largest Contentful Paint měří čas vykreslení největšího viditelného obsahového prvku ve viewportu. V praxi to často bývá:

• hero obrázek,
• velký nadpis,
• obrázek hlavního článku,
• produktový obrázek,
• velký blok textu.

LCP se neptá, kdy se dokončilo načítání každého skriptu, tracking pixelu a obrázku pod ohybem stránky. Ptá se: kdy se zobrazila hlavní věc, kvůli které uživatel přišel?

Díky tomu je LCP lidštější metrika než staromódní „doba načtení stránky“. Stránka se technicky může načítat ještě dlouho, ale pořád působit rychle, pokud se hlavní obsah zobrazí brzy. Platí i opak: stránka může spustit událost load, zatímco hero oblast je stále prázdná, rozmazaná nebo blokovaná zpožděním vykreslení.

Běžné příčiny špatného LCP

Většina problémů se špatným LCP pochází z několika předvídatelných míst:

1. Pomalá odezva serveru

Pokud HTML dokument dorazí pozdě, všechno ostatní začne pozdě.

1. CSS nebo JavaScript blokující vykreslení

Prohlížeč obsah má, ale ještě ho nemůže vykreslit.

1. Neoptimalizované hero obrázky

Největší prvek je příliš velký, ve špatném formátu, nemá prioritu nebo se omylem načítá lazy-loadem.

1. Web fonty zpožďující vykreslení textu

LCP prvkem může být velký nadpis a načítání fontu ho může zpozdit nebo vizuálně změnit.

1. Zpoždění způsobené client-side renderingem

Pokud stránka potřebuje velký JavaScript bundle, než dokáže zobrazit smysluplný obsah, LCP tím trpí.

Jak zlepšit LCP

Začněte skutečným LCP prvkem. Neoptimalizujte náhodné assety, dokud nevíte, co prohlížeč měří.

Praktické opravy zahrnují:

• Servírujte HTML rychle: používejte cache tam, kde to dává smysl, omezte práci backendu, vyhněte se pomalým přesměrováním.
• Optimalizujte LCP obrázek: použijte správné rozměry, kompresi a formát.
• Nenačítejte lazy-loadem hero obrázek nad ohybem stránky.
• Používejte fetchpriority="high" opatrně pro hlavní obrázek, když je skutečně prioritou.
• Inline kritické CSS používejte jen tehdy, když smysluplně snižuje zpoždění vykreslení.
• Snižte množství JavaScript potřebného před prvním smysluplným vykreslením.
• Použijte font-display: swap nebo jinou záměrnou strategii pro fonty.

Obrázky a fonty bývají častými viníky. U obrázků nejde jen o jednoduché „malý soubor je dobrý“. Záleží na volbě formátu, úsilí při kódování i podpoře v prohlížečích, proto udržujeme praktický rozhodovací strom pro situace, kdy AVIF překonává WebP a kdy ne. U stránek s velkým množstvím textu jsou web fonty stále jedním z nejsnazších výkonnostních zlepšení, protože mnoho webů posílá více souborů fontů, než skutečně používá.

INP: reaguje stránka na dotyk?

Interaction to Next Paint měří odezvu. Přesněji sleduje prodlevu mezi uživatelskou interakcí a další vizuální aktualizací poté, co prohlížeč tuto interakci zpracoval.

Mezi interakce patří například:

• kliknutí na tlačítko,
• klepnutí na menu,
• výběr checkboxu,
• psaní do formulářového pole,
• otevření akordeonu.

INP nahradilo First Input Delay jako Core Web Vital v roce 2024. Byla to dobrá změna. First Input Delay sledoval pouze první interakci. INP je širší: bere v úvahu interakce během celé návštěvy stránky a jako skóre odezvy stránky hlásí interakci s vysokou latencí.

Jednoduše řečeno: INP odhaluje stránky, které vypadají načtené, ale působí zaseknutě.

Takovou stránku jste pravděpodobně už použili. Vypadá připraveně. Klepnete na menu. Půl sekundy se nic neděje. Klepnete znovu. Pak se stanou dvě věci najednou. To je problém INP.

Běžné příčiny špatného INP

INP je obvykle problém hlavního vlákna. Prohlížeč chce reagovat, ale v cestě mu stojí JavaScript, vykreslovací práce nebo výpočet rozvržení.

Typické příčiny zahrnují:

• velké JavaScript bundle,
• náročné event handlery,
• hydration práce u client-rendered aplikací,
• skripty třetích stran soutěžící o hlavní vlákno,
• dlouho běžící úlohy po načtení stránky,
• složité aktualizace DOM vyvolané malými interakcemi,
• layout thrashing, kdy kód opakovaně čte a zapisuje hodnoty rozvržení.

Marketingové tagy, analytika, chatovací widgety a consent bannery k tomu mohou přispívat. Neznamená to „všechno odstranit“. Znamená to, že každý skript na stránce něco stojí a latence interakcí je místo, kde je tato cena často vidět.

Jak zlepšit INP

Zlepšování INP není ani tak o jednom zázračném atributu jako spíš o snížení soupeření o hlavní vlákno.

Užitečné přístupy zahrnují:

• Rozdělte dlouhé JavaScript úlohy na menší části.
• Odložte nepodstatnou práci až na dobu, kdy je stránka použitelná.
• Odstraňte nepoužívaný JavaScript místo toho, abyste ho jen minifikovali.
• Udržujte event handlery malé a předvídatelné.
• Vyhněte se překreslování velkých částí rozhraní kvůli drobným změnám stavu.
• Pro jednoduché vizuální stavy používejte CSS, kde je to možné.
• Auditujte skripty třetích stran a načítejte je jen tam, kde jsou potřeba.

Podívejte se také na návrh interakcí. Tlačítko, které poskytne okamžitou vizuální zpětnou vazbu, může působit rychleji, i když navazující práce trvá déle. Není to náhrada výkonu, ale je to součást dobrého návrhu rozhraní. Náš checklist pro přístupná webová tlačítka se s tím překrývá: jasné stavy, správná sémantika a předvídatelné chování pomáhají uživatelům i prohlížečům.

CLS: zůstává stránka tam, kde ji uživatel očekává?

Cumulative Layout Shift měří neočekávaný pohyb viditelných prvků. Pokud uživatel začne číst odstavec a nad ním se načte reklama, obrázek nebo banner, který text posune dolů, přispívá to k CLS.

CLS se neměří v sekundách. Je to skóre založené na tom, kolik obsahu se pohnulo a jak daleko se pohnulo. Nižší je lepší.

Klíčové slovo je neočekávaný. Změny rozvržení způsobené akcí uživatele se obvykle nepočítají stejným způsobem. Pokud někdo klepne na „zobrazit více“ a obsah se rozbalí, je to očekávané. Pokud se po třech sekundách nahoře objeví newsletter banner a všechno posune dolů, očekávané to není.

Běžné příčiny špatného CLS

Selhání CLS bývají často obyčejná:

• obrázky bez atributů width a height,
• reklamy nebo embedy bez rezervovaného prostoru,
• cookie bannery vložené nad obsah,
• web fonty, které se přepnou s odlišnými metrikami,
• pozdě načítané promo lišty,
• dynamicky vložený obsah poblíž horní části stránky.

Oprava obvykle spočívá v rezervování prostoru ještě předtím, než obsah dorazí. Prohlížeč by měl znát tvar stránky co nejdříve.

Jak zlepšit CLS

Začněte viditelnými posuny. Podívejte se na záznam nebo použijte nástroje prohlížeče a zjistěte, které prvky se hýbou.

Pak aplikujte nudné opravy:

• Přidejte k obrázkům explicitní atributy width a height.
• Pro responzivní mediální kontejnery používejte CSS aspect-ratio.
• Rezervujte pevný nebo minimální prostor pro reklamy, embedy a iframe.
• Nevkládejte bannery po načtení nad existující obsah.
• Volte fallback fonty s metrikami podobnými finálnímu fontu.
• Vyhněte se animacím, které mění layout vlastnosti jako top, left, width nebo height; preferujte transformace.

CLS je jedna z mála výkonnostních metrik, kde disciplína poráží chytrost. Pokud má stránka stabilní boxy, obvykle dosahuje dobrého skóre.

Field data a lab data jsou užitečná, ale odpovídají na různé otázky

Běžným zdrojem zmatku je, že různé nástroje ukazují různá čísla. To je normální.

Field data pocházejí od skutečných uživatelů. Odráží reálná zařízení, sítě, lokality a podmínky v prohlížeči. Google Chrome User Experience Report je příkladem field data.

Lab data pocházejí z kontrolovaného testovacího prostředí. Známým příkladem je Lighthouse. Jsou opakovatelná a užitečná pro ladění, ale nejsou totéž jako skutečná zkušenost vašich uživatelů.

Field data používejte k rozhodnutí, zda uživatelé skutečně mají problém. Lab data používejte k reprodukci a ladění tohoto problému.

Pamatujte také, že Core Web Vitals se obvykle posuzují pro jednotlivé URL nebo skupiny URL, ne jako jedna abstraktní vlastnost vaší značky. Domovská stránka, článek na blogu, ceník a checkout mohou mít velmi odlišná úzká místa.

Rozumné pořadí práce

Pokud jsou špatné všechny tři metriky, láká to začít všude. Odolejte tomu.

Praktické pořadí je:

1. Nejprve opravte zjevné CLS

Chybějící rozměry obrázků a nestabilní bannery bývají rychlá vítězství.

1. Zlepšete LCP u důležitých šablon

Zaměřte se na stránky, na kterých záleží: produktové stránky, landing pages, články, registrační flow.

1. Zkoumejte INP pomocí skutečných interakcí

Klikejte na věci, na které uživatelé skutečně klikají. Menu, filtry, formuláře a ovládací prvky checkoutu často odhalí více než stopa počátečního načtení.

1. Auditujte skripty třetích stran

Nechte ty, které obhájí svou cenu. Odstraňte nebo odložte ty, které ji neobhájí.

1. Nastavte výkonnostní rozpočet

Bez rozpočtu se zlepšení výkonu postupně rozpadnou. Nové skripty, obrázky a designové komponenty práci nenápadně vrátí zpět.

Důležitý bod: neoptimalizujte kvůli odznaku. Optimalizujte uživatelskou cestu. Okrajové zlepšení skóre na stránce s nízkou návštěvností může být méně důležité než mírně nedokonalá, ale mnohem rychlejší interakce v checkoutu.

<!-- tool-cta:start -->

💡 Vyzkoušejte toto: Protože LCP je obvykle problém s obrázkem, zmenšete svůj hlavní obrázek pomocí Image Compressor jako první snadnou výhru.

<!-- tool-cta:end -->

Co vám Core Web Vitals neřeknou

Core Web Vitals jsou užitečné, ale neúplné.

Neřeknou vám, zda je váš obsah dobrý. Neřeknou vám, zda vaše navigace dává smysl. Nezaručují přístupnost. Neměří soukromí, bezpečnost, důvěryhodnost, čitelnost ani to, zda stránka odpovídá na otázku uživatele.

Také nenahrazují úsudek. Stránka může projít Core Web Vitals a přesto být nepříjemná. Složitá aplikace může nesplnit prahovou hodnotu a přesto být odpovědně navržená vzhledem ke svým omezením.

Berte LCP, INP a CLS jako kouřové hlásiče. Když se ozvou, zkoumejte proč. Když mlčí, dál se starejte o budovu.