Návštěvník klepne na odkaz a místo obsahu uvidí prázdnou plochu. O dvě sekundy později se objeví obrázek, po další chvíli nadpis a právě ve chvíli, kdy chce stisknout tlačítko, stránka mu ho odsune níž. Web možná není rozbitý. Jen se chová tak, že ho člověk raději zavře.
Právě tady začínají Core Web Vitals. Nejsou to abstraktní body pro vývojáře, ale měření tří konkrétních problémů: jak rychle se zobrazí hlavní obsah, jak svižně stránka reaguje na akci a zda se během načítání neposouvá pod rukama.
Aktuální trojici tvoří LCP, INP a CLS. Metrika INP v březnu 2024 nahradila dřívější FID, protože lépe zachycuje celkovou odezvu stránky během návštěvy, ne pouze první interakci.
LCP neboli Largest Contentful Paint sleduje okamžik, kdy se zobrazí největší viditelný prvek v úvodní části stránky. Často jde o hlavní fotografii, velký nadpis nebo výrazný blok s textem. Dobrá hodnota nepřesahuje 2,5 sekundy, nad 4 sekundy už je výsledek považován za špatný.
Tohle není soutěž o nejmenší číslo za každou cenu. Čtenář nepotřebuje vidět šedou kostru stránky za půl sekundy, když se skutečný obsah objeví až později. LCP začíná bolet ve chvíli, kdy člověk neví, zda se stránka načítá, nebo se prostě zasekla.
Největší viník bývá překvapivě obyčejný: obrázek. U 73 procent mobilních stránek je právě obrazový prvek tím, co určuje LCP. Rozměry souboru, komprese, priorita načítání i to, jak pozdě se obrázek objeví v HTML, mohou rozhodnout o tom, zda se hlavní obsah zobrazí včas.
Příliš velká fotografie z fotobanky je na mobilu skoro jako stěhovat klavír výtahem určeným pro jednu osobu. Problém nemusí vyřešit ani rychlý server, protože prohlížeč stále musí stáhnout, dekódovat a vykreslit data, která stránka do úvodního pohledu vůbec nepotřebuje.
Zvláštní pozornost si zaslouží obrázky načítané přes skripty nebo vložené až po vykreslení základní struktury stránky. Prohlížeč je objeví pozdě, a tím se zpozdí i LCP. Pomáhá vhodný formát, rozumná velikost, správné rozlišení pro konkrétní zařízení a jasně nastavená priorita hlavního vizuálu.
INP měří odezvu na uživatelské akce. Kliknutí na menu, otevření filtru nebo odeslání formuláře by nemělo skončit několikasetmilisekundovým tichem, během kterého člověk neví, zda jeho pokyn vůbec prošel. Dobrá hodnota INP je nejvýše 200 milisekund, špatné výsledky začínají nad 500 milisekundami.
Pomalá odezva často nesouvisí s připojením. Stránka může být načtená, ale hlavní vlákno prohlížeče zaměstná dlouhý JavaScript, reklamní systém, analytika nebo složitá animace. Tlačítko pak sice vypadá připraveně, jenže prohlížeč zrovna řeší jinou práci.
Tady se ukazuje nepohodlná otázka: potřebuje web opravdu všechny skripty, které na něj marketing postupně navěsil? Každý doplněk bývá obhajován jako malá věc. V součtu ale může z jednoduché stránky vzniknout přeplněná kancelář, kde se všichni snaží mluvit najednou.
Třetí metrika, CLS neboli Cumulative Layout Shift, zachycuje neočekávané posuny rozvržení. Čtenář začne číst titulek a najednou mu před něj skočí reklamní plocha. Kliká na odkaz a místo něj trefí jiné tlačítko. Dobrá hodnota CLS nepřesahuje 0,1, špatná začíná nad 0,25.
Příčinou bývají obrázky bez předem určených rozměrů, pozdě načítané fonty, reklamní kontejnery nebo prvky vložené do stránky až po jejím zobrazení. Prostor pro ně musí existovat dříve, než se jejich obsah objeví. Jinak prohlížeč nejprve stránku poskládá a potom ji znovu přestaví přímo před očima návštěvníka.
Hodnotit web podle jediného měření by bylo stejně zavádějící jako posuzovat auto jen podle zrychlení. Stránka splní požadavky Core Web Vitals teprve tehdy, když projde všemi třemi metrikami na 75. percentilu návštěv. Výsledky se navíc posuzují odděleně pro mobilní zařízení a počítače.
To znamená, že několik rychlých testů v kanceláři nic negarantuje. Rozhodující je zkušenost širšího vzorku skutečných návštěvníků v různých podmínkách. Mobil s horším připojením, starším procesorem a menší pamětí odhalí slabiny, které vývojář na výkonném notebooku snadno přehlédne.
Čísla přitom nejsou příliš povzbudivá. Přibližně 40 procent webů sledovaných v Chrome UX Reportu nesplňuje doporučený limit pro LCP. U stránek se špatným LCP se načtení hlavního obrázku na 75. percentilu v průměru zpožďuje o 1 290 milisekund. To je dost dlouhá doba na to, aby návštěvník změnil názor.
Praktická optimalizace proto nezačíná nákupem výkonnějšího serveru. Nejdřív je třeba zjistit, co přesně tvoří LCP, které skripty blokují hlavní vlákno a proč se rozvržení posouvá. Teprve potom dává smysl řešit mezipaměť, síť, serverové odpovědi nebo způsob doručování zdrojů.
Rychlost se také nesmí měřit jen na titulní stránce. E-shop může mít svižnou homepage a katastrofálně pomalý produktový detail. Zpravodajský web zvládne rychle zobrazit text, ale přidusí se pod reklamními skripty. Hodnocení je obecně zaměřené na konkrétní stránku, ne na jakousi magickou vlastnost celé domény.
Core Web Vitals Google používá v hodnoticích systémech vyhledávání, což z nich dělá legitimní součást technické péče o web. Dobré skóre však samo o sobě vysokou pozici nezaručí. Skvěle optimalizovaná stránka bez užitečného obsahu nepřeskočí automaticky kvalitnější konkurenci jen proto, že se vykreslí o několik set milisekund rychleji.
Přesto by byla chyba brát metriky jako kosmetiku pro report. LCP, INP a CLS popisují velmi konkrétní okamžiky, kdy se návštěvník rozhoduje, zda stránce věřit. A když hlavní obrázek dorazí pozdě, tlačítko nereaguje nebo obsah uhýbá pod prstem, žádné zelené kolečko v testu ten první dojem nevrátí.
