Core Web Vitals: Co znamenají a jak ověřit jejich zlepšení
Web v kanceláři působí rychle, ale mobilní report ukazuje problém. Nejdřív zjistěte, kterou zkušenost kazí: načítání obsahu, reakci na kliknutí, nebo posouvání stránky. Potom opravte konkrétní příčinu a ověřte ji ve stejných podmínkách.
01Začněte stránkou a úkolem zákazníka
Váš zákazník otevře detail produktu, změní variantu a vloží zboží do košíku. Každý krok může zdržovat jiná věc. Obecné zadání „zrychlete web“ proto nahraďte adresou stránky, typem zařízení a popisem potíží. Vývojář potřebuje umět problém zopakovat.
Vyberte nejprve jednu důležitou šablonu, například detail služby nebo objednávku. Zapište datum, verzi webu, použitý nástroj a výchozí hodnoty. Pokud zároveň změníte obrázky, hosting i měření, bude obtížné určit, která úprava pomohla. Lepší zadání spojuje jeden problém, jednu hypotézu a způsob ověření.
02Tři metriky popisují tři různé problémy
Dokumentace Core Web Vitals pracuje s LCP, INP a CLS. Doporučené hranice se posuzují na 75. percentilu, odděleně pro mobil a počítač. Jednoduše řečeno sledujete hodnotu, do které se vejdou tři čtvrtiny zaznamenaných návštěv, nikoli průměr.
| Metrika | Dobrá hodnota | Co prověřit |
|---|---|---|
| LCP | Nejvýše 2,5 s | Kdy se vykreslí hlavní obsah |
| INP | Nejvýše 200 ms | Odezvu při klikání a psaní |
| CLS | Nejvýše 0,1 | Nečekané posuny rozložení |
LCP se týká největšího viditelného obrázku nebo textového bloku. INP hodnotí odezvu při interakcích během návštěvy, ne jen při prvním načtení. CLS je bezrozměrné skóre nečekaných posunů rozložení. Dobré číslo u jedné metriky nevyváží problém u jiné. U všech proto zachovejte jejich vlastní jednotku a hranici.
03Rozlišujte data lidí a jeden laboratorní test
V PageSpeed Insights si nejdřív všimněte, zda report ukazuje konkrétní URL, nebo celý origin. Origin obvykle sdružuje stránky se stejným protokolem, doménou a portem. Výsledek celé domény nemusí popisovat právě váš produktový detail. Chybějící veřejná data také neznamenají, že stránka testem prošla.
Google popisuje data CrUX v PageSpeed Insights jako průběžně aktualizovaný souhrn posledních 28 dní. Po dnešním nasazení proto nečekejte okamžitý přepis celého období. Laboratorní test použijte k hledání příčin a rychlé kontrole změny, data návštěvníků k potvrzení skutečné zkušenosti.
Samotný automatický běh Lighthouse bez interakcí nezměří INP. Má pomocnou metriku Total Blocking Time. Její zlepšení berte jako užitečný signál, ale nenahrazujte jím výsledek INP z provozu. Interaktivní části projděte v nástrojích pro vývojáře při skutečném klikání a psaní.
04U LCP zjistěte, na co prohlížeč čeká
Pomalý hlavní obrázek není automaticky příliš velký. Postup pro optimalizaci LCP rozlišuje odpověď serveru, prodlevu před zahájením stahování, samotný přenos a čekání na vykreslení. Oprava má mířit na část, která na konkrétní stránce zdržuje.
Nechte si v záznamu ukázat skutečný LCP prvek. Jestli se důležitý obrázek objeví v HTML až po spuštění skriptu, řešte jeho dřívější dostupnost. Pokud přenos už skončil a obsah stále není vidět, další komprese souboru nemusí vyřešit čekání na zobrazení. Obrázek, který tvoří LCP, nenačítejte líně pomocí lazy loadingu.
Následující model ukazuje pouze aritmetiku jednoho ilustračního načtení. Zkrácení prodlevy před stažením z 900 na 100 ms při nezměněných ostatních časech sníží součet z 2 700 na 1 900 ms. Nejde o měření klientského webu, percentil ani příslib výsledku. V provozu se po změně mohou proměnit i další části.
- Odpověď serveruPřed změnou: 600Po změně: 600
- Prodleva před staženímPřed změnou: 900Po změně: 100
- Stažení zdrojePřed změnou: 400Po změně: 400
- Prodleva vykresleníPřed změnou: 800Po změně: 800
Ilustrační hodnoty LISTIFY, nikoli měření webu. Jednotka: ms. Součet před: 2 700 ms, po: 1 900 ms. Mění se pouze prodleva před stažením.
05U INP opakujte pomalou interakci
Sepište, zda se problém objevuje při otevření menu, filtrování katalogu, zadávání textu nebo potvrzení formuláře. V záznamu výkonu pak hledejte, co v té chvíli zaměstnává hlavní vlákno prohlížeče. Neposuzujte odezvu jen podle toho, za jak dlouho server vrátí požadavek.
Doporučení pro INP rozlišuje čekání na zpracování vstupu, běh obsluhy a prodlevu do dalšího vykreslení. Vlastní úpravu ověřte na stejné akci. Může jít o rozdělení dlouhé práce, omezení nepotřebných skriptů nebo zmenšení rozsahu překreslované části. Na slabším telefonu znovu zkontrolujte také správnost výsledku.
06U CLS rezervujte prostor předem
Pokud zákazník míří na tlačítko a pod prstem se mu objeví jiný obsah, najděte prvek, který rozložení posunul. Dokumentace k CLS řeší mimo jiné obrázky bez rozměrů a dodatečně vkládaný obsah. Prostor pro obrázek, reklamu či vložený prvek má být známý před jejich načtením.
Projděte také načtení webového písma, otevření oznámení a doplnění výsledků pod formulářem. Nečekané přeskočení obsahu nemusí vzniknout hned na začátku. Ve svém kontrolním scénáři proto stránku i posouvejte a používejte. Oprava velikosti úvodního obrázku neprokazuje stabilitu celé návštěvy.
07Předejte opravu s měřitelnou podmínkou dokončení
Do jednoho pracovního úkolu napište adresu, scénář, postižené zařízení, výchozí záznam a očekávanou změnu. Připojte i kontrolu funkce. Odstranění skriptu sice může zrychlit stránku, ale pokud přestane fungovat košík, není práce dokončená.
- Před změnou uložte několik opakování za stejných podmínek.
- Po změně zopakujte stejný scénář a porovnejte příslušnou část záznamu.
- Poznamenejte nasazení, abyste jej našli v provozních datech.
- Po získání dostatečného vzorku posuďte výsledek návštěvníků a další šablony.
U webu s malou návštěvností mohou veřejné reporty chybět. V takovém případě zvažte vlastní měření skutečných návštěv s přiměřeným rozsahem sběru. Do výkonnostních událostí neposílejte hodnoty polí ani osobní údaje. Malý vzorek popište jako omezení, nepřevádějte několik měření na jistý závěr o všech zákaznících.
08Zelený report je podklad pro rozhodnutí
Google Search Central uvádí, že dobré Core Web Vitals samy nezaručují přední pozice. Vedle výkonu sledujte, zda lidé dokončí úkol, najdou potřebné informace a zda funguje obsah i ovládání. Technické zlepšení a obchodní výsledek měřte odděleně.
Při opakování testu zachovejte typ zařízení, omezení sítě a stav mezipaměti. První otevření bez uložených souborů a návrat návštěvníka nejsou stejné podmínky. K výsledku připište také testovaný scénář. Jinak můžete za zlepšení zaměnit jen rychlejší připojení nebo obsah, který už prohlížeč jednou stáhl.
Pokud se výkon po několika týdnech vrátí zpět, hledejte novou změnu: vloženou službu, jiný obrázek nebo úpravu šablony. Určete vlastníka kontroly po nasazení. Jednorázové zrychlení má malý smysl, pokud další redakční úprava znovu načítá obří obrázek.
Chcete zadat opravu, kterou půjde převzít podle důkazů? Připravte URL, problémový scénář a výchozí report. Při úpravě webu na míru tak můžete rozhodovat podle konkrétní příčiny a ověřeného výsledku.