Core Web Vitals sú tri metriky: LCP (do 2,5 s), INP (do 200 ms) a CLS (do 0,1), posudzované na 75. percentile skutočných návštev. Pôvodne bol tretím údajom FID, no ten od 12. marca 2024 nahradilo INP. Google tieto metriky používa v rankingových systémoch, nie sú však jediným signálom a dokonalé skóre netreba naháňať. Rýchlosť sa oplatí merať v dvoch druhoch dát, laboratórnych aj terénnych, a upravovať konkrétne príčiny: obrázky, skripty, rozmery prvkov, cache a server. V článku nájdete hranice metrík, postup merania, zásahy pre LCP, INP a CLS a modelový príklad.
Čo sú Core Web Vitals a aké hodnoty sú dobré?
Core Web Vitals sú metriky používateľskej skúsenosti, ktoré merajú rýchlosť načítania, odozvu a vizuálnu stabilitu. Stránka prejde, ak spĺňa hranice „dobré“ pre všetky tri metriky na 75. percentile návštev, zvlášť pre mobil a pre počítač. Tretia metrika sa zmenila: FID, ktoré merali len oneskorenie prvej interakcie, nahradilo INP, ktoré zohľadňuje interakcie počas celej návštevy.
| Metrika | Čo meria | Dobré | Treba zlepšiť | Slabé |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Za aký čas sa zobrazí najväčší prvok obsahu, napríklad hlavný obrázok alebo nadpis | do 2,5 s | do 4 s | nad 4 s |
| INP (Interaction to Next Paint) | Ako rýchlo stránka reaguje na kliky, ťuknutia a klávesy počas celej návštevy | do 200 ms | do 500 ms | nad 500 ms |
| CLS (Cumulative Layout Shift) | Koľko sa obsah počas načítania nečakane posúva | do 0,1 | do 0,25 | nad 0,25 |
Hodnoty sa posudzujú podľa terénnych dát zo skutočných návštev, nie podľa jedného testu. V Search Console má skupina URL stav podľa najslabšej metriky, takže jedna slabá hodnota ťahá celú skupinu dole.
Prečo na rýchlosti webu záleží?
Návštevníci neradi čakajú. Štúdia Google a SOASTA z roku 2017 uvádza, že 53 % mobilných návštevníkov odíde zo stránky, ktorá sa načítava dlhšie než tri sekundy. Ide o staršie dáta, preto ich berte ako ilustráciu, nie ako aktuálnu hranicu. Pomalý web zároveň zhoršuje používateľský zážitok, a to aj tam, kde si ho nik nevšimne v štatistikách.
Google uvádza, že Core Web Vitals používajú jeho rankingové systémy, a odporúča ich dosiahnuť pre úspech vo vyhľadávaní aj pre používateľský zážitok. Zároveň upozorňuje, že neexistuje jeden signál „page experience“, že dobré skóre samo o sebe nezaručí vysokú pozíciu a že naháňanie dokonalých hodnôt kvôli SEO nemusí byť dobrým využitím času. Rýchly web je preto základ, nie zázračný trik.
Ako rýchlosť správne zmerať: laboratórne alebo terénne dáta?
Rovnaký web môže mať v rôznych nástrojoch rôzne výsledky, pretože nástroje merajú rôzne veci. PageSpeed Insights ukazuje terénne dáta z Chrome UX Report za posledných 28 dní a vedľa nich laboratórny test z Lighthouse. Laboratórny test beží z dátových centier Google v Severnej Amerike, Európe alebo Ázii, nie nutne z USA, ako sa často tvrdí.
- Čo to je: Simulované načítanie stránky v kontrolovanom prostredí
- Zariadenie a sieť: Jedno emulované zariadenie a sieť, test beží z dátového centra v Severnej Amerike, Európe alebo Ázii
- Obdobie: Jedno meranie teraz
- Na čo sa hodí: Hľadanie príčin a overenie úprav pred nasadením
- Slabá stránka: Nevie predpovedať, kedy návštevník klikne, takže INP nezmeria skutočne
- Čo to je: Dáta zo skutočných návštev používateľov Chrome
- Zariadenie a sieť: Rôzne zariadenia, siete a miesta návštevníkov
- Obdobie: Predchádzajúcich 28 dní, v PageSpeed Insights sa aktualizuje denne
- Na čo sa hodí: Rozhodovanie, čo opraviť ako prvé, a posúdenie Core Web Vitals
- Slabá stránka: Vidí len ľudí, ktorým sa web podarilo načítať
- Najprv sa pozrite na terénne dáta. Podľa nich sa rozhodujte, čo opraviť ako prvé, pretože ukazujú, čo zažívajú skutoční návštevníci.
- Laboratórny test použite na hľadanie príčin. Hodí sa na ladenie a na overenie úpravy pred nasadením.
- Report Core Web Vitals v Search Console sledujte pravidelne. Ukazuje skupiny podobných stránok zvlášť pre mobil a počítač. Nový web môže mať dáta až po niekoľkých dňoch.
- Počítajte s oneskorením. Terénne dáta pokrývajú 28 dní, takže zlepšenie sa prejaví postupne.
Ako zlepšiť LCP, teda rýchlosť načítania hlavného obsahu?
LCP sa skladá zo štyroch častí a väčšina času by mala ísť na načítanie HTML a hlavného zdroja, nie na čakanie. Podľa web.dev je pri 73 % mobilných stránok prvkom LCP obrázok, preto sú obrázky najčastejším miestom zlepšenia.
Čo to je: Kým prehliadač dostane začiatok HTML
Čo urobiť: Menej presmerovaní, rýchlejší server, cache a CDN
Čo to je: Medzi TTFB a začiatkom sťahovania hlavného obrázka
Čo urobiť: Obrázok musí byť viditeľný v HTML, nie až po spustení skriptu
Čo to je: Samotné sťahovanie obrázka alebo fontu
Čo urobiť: Menšie súbory, moderné formáty, CDN
Čo to je: Od stiahnutia po zobrazenie prvku
Čo urobiť: Menej blokujúceho CSS a skriptov v hlavičke
Načítajte hlavný obrázok cez img, nie cez skript alebo CSS. Web.dev uvádza, že 35 % obrázkov LCP nie je v úvodnom HTML dohľadateľných.
Atribút fetchpriority="high" na hlavnom obrázku povie prehliadaču, že ho má načítať skôr. Použite ho len na jeden alebo dva kľúčové obrázky.
Komprimujte a zmenšite obrázky, použite moderné formáty ako WebP alebo AVIF a využite CDN.
Neponechávajte v hlavičke zbytočné CSS a synchrónne skripty.
Menej presmerovaní a cache skracujú čas do prvého bajtu.
Pozor na lazy loading: web.dev odporúča nikdy neodkladať načítanie LCP obrázka, pretože sa tým požiadavka oddiali až po rozložení stránky. Analýza stránok ukázala, že stránky s lazy loadingom mali medián LCP 3 546 ms, kým bez neho 2 922 ms. Ide o koreláciu, no odporúčanie je jasné: lazy loading patrí obrázkom pod prvou obrazovkou, nie hlavnému obrázku. Častá rada „použite lazy loading na zlepšenie LCP“ preto pre hlavný obrázok neplatí.
Ako zlepšiť INP, teda odozvu stránky?
INP meria latenciu interakcií počas návštevy a podľa web.dev je „dobré“ do 200 ms. Interakcia má tri fázy: oneskorenie vstupu, spracovanie a oneskorenie zobrazenia. Zdrojom problémov býva JavaScript, ktorý blokuje hlavné vlákno prehliadača, hlavne pri štarte stránky.
Úlohy dlhšie než 50 ms sa považujú za dlhé a oneskorujú odozvu. Prácu rozdeľte, aby sa mohli vykonať ďalšie interakcie.
Nepoužívaný kód, staré tagy v správcovi značiek a zbytočné pluginy zaťažujú hlavné vlákno.
Malý DOM a jednoduchšie rozloženie skracujú čas vykreslenia.
Ak ich potrebujete, načítajte ich cez async alebo defer, čím nebudú blokovať vykresľovanie.
| Bez atribútu | async | defer | |
|---|---|---|---|
| Spustenie skriptu | Hneď, parsovanie HTML čaká | Hneď po stiahnutí | Po spracovaní dokumentu |
| Poradie skriptov | Podľa dokumentu | Nezaručené | Zaručené podľa dokumentu |
| Vhodné pre | Zriedka | Nezávislé skripty, napríklad analytika | Skripty závislé na DOM alebo na sebe |
Web.dev uvádza, že oveľa menej webov spĺňa hranicu INP než predtým spĺňalo FID, takže mnohé tímy sa odozvou zaoberajú prvýkrát. Ak vám INP vychádza slabo, nehľadajte príčinu v obrázkoch, ale v skriptoch.
Ako zlepšiť CLS, teda stabilitu rozloženia?
CLS sa zhoršuje, keď sa obsah po načítaní posunie, napríklad keď sa dotiahne obrázok, banner alebo reklama. Dobrá hodnota je do 0,1. Web.dev uvádza, že 66 % stránok má aspoň jeden obrázok bez explicitných rozmerov.
Uveďte atribúty width a height, alebo použite CSS aspect-ratio, aby prehliadač rezervoval miesto vopred.
Použite min-height alebo pomer strán. Ak sa reklama nenačíta, nechajte zástupný blok, aby sa rozloženie nezrútilo.
Banner alebo formulár, ktorý sa objaví po načítaní, nemá tlačiť obsah nadol. Radšej ho prekryte alebo mu vopred vyhraďte miesto. Súvisí to aj s lištou na súhlas, ktorú rozoberá článok GDPR, cookies a zákonné povinnosti na webe.
Zvoľte vhodný záložný font a preload dôležitých fontov, aby sa text po načítaní nepreskakoval.
Animácie vlastností ako top či margin môžu spôsobovať posuny, zatiaľ čo transform nie.
Čo robí cache, CDN a hosting?
Cache, CDN a hosting riešia hlavne čas do prvého bajtu a sťahovanie súborov. CDN je sieť serverov, ktorá doručuje obsah z miesta bližšieho k návštevníkovi. Podľa web.dev skracuje latenciu, ukladá obsah do cache, komprimuje textové odpovede a môže optimalizovať obrázky. Pre statické súbory sa odporúča dlhá platnosť cache, pre často meniaci sa obsah krátka.
Pri opakovanej návšteve sa web načíta rýchlejšie. Po úprave obsahu treba cache vymazať, aby návštevníci videli aktuálnu verziu.
Najviac pomáha pri návštevníkoch vzdialených od servera. Skontrolujte hlavičky Cache-Control a či je zapnuté HTTP/2 a HTTP/3.
Textové súbory komprimujte (Brotli alebo gzip) a kód minifikujte pri zdroji.
Odozva servera tvorí časť LCP. Ak je čas do prvého bajtu dlhý, problém nevyrieši ani dokonalá optimalizácia obrázkov.
Každý zbytočný skript zaťažuje stránku. Vyhoďte tie, ktoré neprinášajú hodnotu, a staré tagy v správcovi značiek.
Prečo nemusí každý web načítať do dvoch sekúnd?
Nie každá stránka sa dokáže načítať za sekundu či dve. Jednoduchý prezentačný web sa dá optimalizovať na takmer okamžité zobrazenie, no rozsiahly portál s kalkulačkami, prepojením na externé systémy, jazykovými verziami alebo e-shop s filtrami potrebuje viac času. Web.dev uvádza, že LCP je najťažšia z troch metrík: približne 40 % webov v Chrome UX Report hranicu LCP nespĺňa. Zlepšiť sa dá takmer každý web, no očakávania treba nastaviť podľa rozsahu a zložitosti projektu.
Cieľom nie je presné číslo, ale aby hranice splnila väčšina reálnych návštev. Ak ich spĺňate, ďalšie zlepšovanie prináša čoraz menší úžitok.
Príklad z praxe: keď pomalý web brzdí veľký úvodný obrázok
Nasledujúci modelový príklad zhŕňa najčastejší scenár pri pomalých firemných weboch. Nejde o konkrétneho klienta a neuvádza vymyslené čísla.
Firma mala pekný web s veľkým úvodným obrázkom a niekoľkými doplnkami. Stránka pôsobila pomaly a PageSpeed Insights hlásil slabé LCP aj varovania ohľadom skriptov.
Hlavný obrázok mal príliš veľký súbor, bol zapnutý lazy loading aj pre úvodný obrázok a obrázok sa dotiahol až skriptom. Skripty tretích strán sa načítavali bez defer, takže blokovali vykresľovanie.
Obrázok zmenšiť, uložiť v modernom formáte, pridať mu rozmery a fetchpriority="high" a vypnúť pre neho lazy loading. Skripty načítať cez defer alebo async a zbytočné odstrániť.
V laboratórnom teste sa zlepšenie ukázalo hneď po nasadení. V Search Console sa prejavilo až po niekoľkých týždňoch, pretože terénne dáta pokrývajú 28 dní.
Záver: rýchlosť webu je proces, nie jednorazová úprava
Kľúčové závery: Core Web Vitals tvoria LCP do 2,5 s, INP do 200 ms a CLS do 0,1 na 75. percentile skutočných návštev, FID už neplatí. Merajte terénne aj laboratórne dáta a nespoliehajte sa na jeden test. Pri LCP riešte obrázky a čas servera, nikdy neodkladajte hlavný obrázok. Pri INP riešte skripty a pri CLS rozmery a rezervované miesto. Google používa tieto metriky pri hodnotení, no nie sú jediným faktorom, preto nechoďte za dokonalým skóre, ale za webom, ktorý je pre návštevníkov rýchly a stabilný.
Ako ďalej? Ak chcete web, ktorý je rýchly už od návrhu, pozrite si proces tvorby webstránky, portfólio a cenník alebo nás kontaktujte.
Často kladené otázky o Core Web Vitals a rýchlosti webu
Aké hodnoty Core Web Vitals sú dobré?
Čo je INP a prečo FID už neplatí?
Ovplyvňujú Core Web Vitals poradie vo vyhľadávaní?
Prečo sa výsledky PageSpeed Insights a Search Console líšia?
Mám zapnúť lazy loading na všetky obrázky?
Pomôže CDN každému webu?
Koľko sekúnd má trvať načítanie webu?
Ako často testovať rýchlosť webu?
Zdroje
- web.dev: Web VitalsDefinícia Core Web Vitals (LCP, INP, CLS), hodnoty „dobré“ a posudzovanie podľa 75. percentilu.
- web.dev: INP sa 12. marca stáva Core Web VitalNahradenie FID metrikou INP a ukončenie FID v nástrojoch Google.
- web.dev: Optimize Largest Contentful PaintŠtyri časti LCP a odporúčania, vrátane upozornenia nikdy neodkladať načítanie LCP obrázka.
- web.dev: Optimize Interaction to Next PaintFázy interakcie, dlhé úlohy a spôsoby zlepšenia INP.
- web.dev: Optimize Cumulative Layout ShiftRozmery obrázkov, rezervácia miesta pre reklamy a bannery, fonty a animácie.
- web.dev: The most effective ways to improve Core Web Vitals (aktualizované október 2024)Najúčinnejšie zásahy pre INP, LCP a CLS a dáta o ich výskyte na webe.
- web.dev: The performance effects of too much lazy loading (2022)Merania, že odloženie načítania obrázka v prvej obrazovke zhoršuje LCP.
- web.dev: Optimize resource loading with the Fetch Priority APIAtribút fetchpriority a jeho použitie pri LCP obrázku.
- web.dev: Why lab and field data can be differentPrečo sa laboratórne a terénne dáta líšia a ako ich používať spolu.
- Google for Developers: About PageSpeed InsightsTerénne dáta z posledných 28 dní, laboratórny test z dátových centier a posudzovanie Core Web Vitals.
- Search Console Help: Core Web Vitals reportZdroj dát (CrUX), hranice dobrých a slabých hodnôt a skupiny URL.
- Google Search Central: Understanding page experience in Google Search resultsÚloha Core Web Vitals v rankingových systémoch a upozornenie, že samotné skóre nezaručí pozíciu.
- web.dev: Content delivery networks (CDNs)Čo CDN zlepšuje: latenciu, cache, kompresiu a optimalizáciu obrázkov.
- MDN: Element script (async a defer)Rozdiel medzi async a defer pri načítaní skriptov.
- web.dev: Efficiently load third-party JavaScriptAko obmedziť vplyv skriptov tretích strán na rýchlosť.
- AMP Blog: New industry benchmarks for mobile page speed (2017)Štúdia Google/SOASTA z roku 2017: 53 % mobilných návštevníkov odíde zo stránky, ktorá sa načítava dlhšie než tri sekundy. Staršie dáta.