Core Web Vitals zrozumiteľne: LCP, INP a CLS

Core Web Vitals nie sú osobnostný test pre váš web

Core Web Vitals sa často berú ako tajomná hodnotiaca tabuľka. Stránka dostane červené číslo, niekto pošle screenshot do Slacku a tím sa začne hádať o JavaScript frameworkoch.

To nie je zvlášť užitočné.

Lepšie je premýšľať o Core Web Vitals jednoduchšie: sú to tri merania toho, či stránka pôsobí použiteľne pre skutočného človeka na skutočnom zariadení. Nezachytávajú každý aspekt výkonu, prístupnosti ani kvality. Zachytávajú však tri časté zdroje frustrácie:

• Hlavný obsah sa zobrazuje príliš dlho.
• Stránka reaguje pomaly, keď sa používateľ pokúša niečo urobiť.
• Rozloženie počas čítania alebo ťukania poskakuje.

To sú tri Core Web Vitals: LCP, INP a CLS.

Google ich používa ako súčasť signálov page experience, ale SEO pohľad nie je najlepší dôvod, prečo sa o ne zaujímať. Lepší dôvod je ten, že pomalé, poskakujúce a nereagujúce stránky plytvajú časom používateľov. Zvyknú tiež horšie konvertovať, horšie sa podporovať a rýchlejšie starnúť.

Tri metriky jednou vetou

Skôr než pôjdeme do detailov, tu je verzia v bežnej reči:

• LCP, alebo Largest Contentful Paint, meria, ako dlho trvá načítanie hlavného viditeľného obsahu.
• INP, alebo Interaction to Next Paint, meria, ako rýchlo stránka reaguje na používateľské interakcie počas návštevy.
• CLS, alebo Cumulative Layout Shift, meria, ako veľmi sa stránka nečakane presúva.

Bežné prahové hodnoty sú:

| Metrika | Dobré | Potrebuje zlepšenie | Zlé | |---|---:|---:|---:| | LCP | 2,5 s alebo rýchlejšie | 2,5 s – 4,0 s | Viac ako 4,0 s | | INP | 200 ms alebo rýchlejšie | 200 ms – 500 ms | Viac ako 500 ms | | CLS | 0,1 alebo menej | 0,1 – 0,25 | Viac ako 0,25 |

Tieto čísla sa zvyčajne vyhodnocujú na 75. percentile reálnych návštev používateľov. Na tom záleží. Nesnažíte sa vytvoriť jeden dokonalý laboratórny beh. Snažíte sa dosiahnuť dobrú skúsenosť pre väčšinu používateľov vrátane ľudí na pomalších telefónoch a menej spoľahlivých sieťach.

Ak sa pozeráte na automatizovaný report a neviete, kde začať, pomáha oddeliť diagnostiku od paniky. Máme samostatný návod, ako čítať Lighthouse report bez paniky, ktorý tento postup rozoberá podrobnejšie.

LCP: kedy stránka pôsobí načítane?

Largest Contentful Paint meria čas vykreslenia najväčšieho viditeľného obsahového prvku vo viewporte. V praxi to často býva:

• hero obrázok,
• veľký nadpis,
• hlavný obrázok článku,
• produktový obrázok,
• veľký blok textu.

LCP sa nepýta, kedy sa načítal každý script, tracking pixel a obrázok pod prvým zlomom stránky. Pýta sa: kedy sa zviditeľnila hlavná vec, kvôli ktorej používateľ prišiel?

Vďaka tomu je LCP ľudskejšia metrika než staromódny „čas načítania stránky“. Stránka sa môže technicky dokončiť neskoro, ale stále pôsobiť rýchlo, ak sa hlavný obsah zobrazí skoro. Platí aj opak: stránka môže spustiť load event, zatiaľ čo hero sekcia je stále prázdna, rozmazaná alebo blokovaná oneskorením vykreslenia.

Časté príčiny zlého LCP

Väčšina problémov so zlým LCP pochádza z niekoľkých predvídateľných miest:

1. Pomalá odpoveď servera

Ak HTML dokument príde neskoro, všetko ostatné začne neskoro.

1. CSS alebo JavaScript blokujúce vykresľovanie

Prehliadač obsah má, ale ešte ho nemôže vykresliť.

1. Neoptimalizované hero obrázky

Najväčší prvok je príliš veľký, v nesprávnom formáte, bez priority alebo omylom načítavaný lenivo.

1. Webové fonty oneskorujúce vykreslenie textu

Veľký nadpis môže byť LCP prvkom a načítanie fontu ho môže oneskoriť alebo vizuálne zmeniť.

1. Oneskorenia pri client-side renderingu

Ak stránka potrebuje veľký JavaScript bundle skôr, než dokáže zobraziť zmysluplný obsah, LCP trpí.

Ako zlepšiť LCP

Začnite skutočným LCP prvkom. Neoptimalizujte náhodné assety, kým neviete, čo prehliadač meria.

Praktické opravy zahŕňajú:

• Servírujte HTML rýchlo: používajte cache tam, kde to dáva zmysel, znížte prácu backendu, vyhýbajte sa pomalým presmerovaniam.
• Optimalizujte LCP obrázok: použite správne rozmery, kompresiu a formát.
• Nenačítavajte lenivo hero obrázok nad prvým zlomom stránky.
• Používajte fetchpriority="high" opatrne pre hlavný obrázok, keď je naozaj prioritou.
• Inlineujte kritické CSS iba vtedy, keď to zmysluplne znižuje oneskorenie vykreslenia.
• Znížte množstvo JavaScriptu potrebného pred prvým zmysluplným vykreslením.
• Použite font-display: swap alebo inú premyslenú fontovú stratégiu.

Obrázky a fonty sú častí vinníci. Pri obrázkoch nejde len o kompromis „malý súbor je dobrý“. Záleží aj na voľbe formátu, náročnosti kódovania a podpore prehliadačov, preto udržiavame praktický rozhodovací strom pre to, kedy AVIF prekonáva WebP a kedy nie. Pri stránkach s veľkým množstvom textu sú webové fonty stále jedným z najjednoduchších výkonových zlepšení, pretože mnohé weby posielajú viac fontových súborov, než skutočne používajú.

INP: reaguje stránka po dotyku?

Interaction to Next Paint meria odozvu. Presnejšie sleduje oneskorenie medzi používateľskou interakciou a ďalšou vizuálnou aktualizáciou po tom, ako prehliadač túto interakciu spracoval.

Interakcie zahŕňajú napríklad:

• kliknutie na tlačidlo,
• ťuknutie na menu,
• označenie checkboxu,
• písanie do formulárového poľa,
• otvorenie accordionu.

INP v roku 2024 nahradilo First Input Delay ako Core Web Vital. Bola to dobrá zmena. First Input Delay sledoval iba prvú interakciu. INP je širšie: zohľadňuje interakcie počas celej návštevy stránky a ako skóre odozvy stránky reportuje interakciu s vysokou latenciou.

Jednoducho povedané: INP zachytáva stránky, ktoré vyzerajú načítané, ale pôsobia zaseknuto.

Takú stránku ste už pravdepodobne použili. Vyzerá pripravená. Ťuknete na menu. Pol sekundy sa nič nestane. Ťuknete znova. Potom sa naraz stanú dve veci. To je problém s INP.

Časté príčiny zlého INP

INP je zvyčajne problém hlavného vlákna. Prehliadač chce reagovať, ale v ceste mu stojí JavaScript, práca s vykresľovaním alebo výpočet rozloženia.

Typické príčiny zahŕňajú:

• veľké JavaScript bundle,
• náročné event handlery,
• hydratačnú prácu v client-rendered aplikáciách,
• skripty tretích strán súťažiace o hlavné vlákno,
• dlho bežiace úlohy po načítaní stránky,
• zložité aktualizácie DOM vyvolané malými interakciami,
• layout thrashing, keď kód opakovane číta a zapisuje hodnoty rozloženia.

Marketingové tagy, analytika, chat widgety a consent bannery môžu prispievať tiež. Neznamená to „odstráňte všetko“. Znamená to, že každý script na stránke má svoju cenu a latencia interakcií je miesto, kde sa táto cena často stáva viditeľnou.

Ako zlepšiť INP

Zlepšovanie INP je menej o jednom zázračnom atribúte a viac o znižovaní súperenia o hlavné vlákno.

Užitočné prístupy zahŕňajú:

• Rozdeľte dlhé JavaScript úlohy na menšie časti.
• Odložte nepodstatnú prácu až na čas po tom, čo je stránka použiteľná.
• Odstráňte nepoužívaný JavaScript namiesto toho, aby ste ho iba minifikovali.
• Udržujte event handlery malé a predvídateľné.
• Vyhýbajte sa opätovnému renderovaniu veľkých častí rozhrania pri drobných zmenách stavu.
• Používajte CSS pre jednoduché vizuálne stavy, kde je to možné.
• Auditujte skripty tretích strán a načítavajte ich iba tam, kde sú potrebné.

Pozrite sa aj na návrh interakcií. Tlačidlo, ktoré poskytne okamžitú vizuálnu spätnú väzbu, môže pôsobiť responzívnejšie, aj keď následná práca trvá dlhšie. Nie je to náhrada výkonu, ale je to súčasť dobrého inžinierstva rozhrania. Náš checklist pre prístupné webové tlačidlá sa s tým prekrýva: jasné stavy, správna sémantika a predvídateľné správanie pomáhajú používateľom aj prehliadačom.

CLS: zostáva stránka tam, kde ju používateľ očakáva?

Cumulative Layout Shift meria neočakávaný pohyb viditeľných prvkov. Ak používateľ začne čítať odsek a nad ním sa načíta reklama, obrázok alebo banner, ktorý text posunie nadol, prispieva to k CLS.

CLS sa nemeria v sekundách. Je to skóre založené na tom, koľko obsahu sa pohlo a ako ďaleko sa pohlo. Nižšie je lepšie.

Kľúčové slovo je neočakávaný. Zmeny rozloženia spôsobené akciou používateľa sa zvyčajne nepočítajú rovnakým spôsobom. Ak niekto ťukne na „zobraziť viac“ a obsah sa rozbalí, je to očakávané. Ak sa po troch sekundách navrchu objaví newsletter banner a všetko posunie nadol, očakávané to nie je.

Časté príčiny zlého CLS

Zlyhania CLS bývajú často prozaické:

• obrázky bez atribútov width a height,
• reklamy alebo embedy bez vyhradeného priestoru,
• cookie bannery vložené nad obsah,
• webové fonty, ktoré sa vymenia za font s inými metrikami,
• neskoro načítané promo lišty,
• dynamicky vkladaný obsah pri hornej časti stránky.

Oprava zvyčajne spočíva vo vyhradení priestoru ešte pred príchodom obsahu. Prehliadač by mal poznať tvar stránky čo najskôr.

Ako zlepšiť CLS

Začnite viditeľnými posunmi. Pozrite si nahrávku alebo použite nástroje prehliadača na identifikáciu prvkov, ktoré sa hýbu.

Potom použite nudné opravy:

• Pridajte obrázkom explicitné atribúty width a height.
• Použite CSS aspect-ratio pre responzívne mediálne kontajnery.
• Vyhraďte pevný alebo minimálny priestor pre reklamy, embedy a iframy.
• Vyhýbajte sa vkladaniu bannerov nad existujúci obsah po načítaní.
• Vyberte fallback fonty s metrikami podobnými finálnemu fontu.
• Vyhýbajte sa animáciám, ktoré menia vlastnosti rozloženia ako top, left, width alebo height; uprednostnite transformácie.

CLS je jedna z mála výkonových metrík, kde disciplína poráža šikovnosť. Ak má stránka stabilné boxy, zvyčajne dosahuje dobré skóre.

Field data aj lab data sú užitočné, ale odpovedajú na odlišné otázky

Častým zdrojom zmätku je, že rôzne nástroje ukazujú rôzne čísla. To je normálne.

Field data pochádzajú od skutočných používateľov. Odrážajú reálne zariadenia, siete, lokality a podmienky prehliadača. Google Chrome User Experience Report je príklad field data.

Lab data pochádzajú z kontrolovaného testovacieho prostredia. Známym príkladom je Lighthouse. Sú opakovateľné a užitočné pri ladení, ale nie sú tým istým ako reálna skúsenosť vašich používateľov.

Používajte field data na rozhodnutie, či používatelia majú skutočný problém. Používajte lab data na reprodukciu a ladenie tohto problému.

Pamätajte tiež, že Core Web Vitals sa zvyčajne posudzujú po URL alebo skupine URL, nie ako jedna abstraktná vlastnosť vašej značky. Vaša domovská stránka, blogový článok, cenník a checkout môžu mať veľmi odlišné úzke miesta.

Rozumné poradie práce

Ak sú zlé všetky tri metriky, pokušenie je začať všade. Odolajte mu.

Praktické poradie je:

1. Najprv opravte zjavné CLS

Chýbajúce rozmery obrázkov a nestabilné bannery sú často rýchle výhry.

1. Zlepšite LCP pri dôležitých šablónach

Zamerajte sa na stránky, na ktorých záleží: produktové stránky, landing pages, články, registračné flow.

1. Skúmajte INP so skutočnými interakciami

Klikajte na veci, na ktoré používatelia skutočne klikajú. Menu, filtre, formuláre a checkout ovládacie prvky často odhalia viac než počiatočný záznam načítania.

1. Auditujte skripty tretích strán

Nechajte tie, ktoré odôvodnia svoju cenu. Odstráňte alebo odložte tie, ktoré ju neodôvodnia.

1. Nastavte performance budget

Bez rozpočtu sa výkonové zlepšenia rozpadnú. Nové skripty, obrázky a dizajnové komponenty potichu vrátia prácu späť.

Dôležitý bod: neoptimalizujte pre odznak. Optimalizujte pre cestu používateľa. Okrajové zlepšenie skóre na stránke s nízkou návštevnosťou môže byť menej dôležité než mierne nedokonalá, ale oveľa rýchlejšia interakcia v checkoute.

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

💡 Vyskúšajte toto: Keďže LCP je zvyčajne problém s obrázkom, zmenšite svoj hlavný vizuál pomocou Image Compressor ako prvé jednoduché víťazstvo.

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

Čo vám Core Web Vitals nepovedia

Core Web Vitals sú užitočné, ale neúplné.

Nepovedia vám, či je váš obsah dobrý. Nepovedia vám, či vaša navigácia dáva zmysel. Nezaručujú prístupnosť. Nemerajú súkromie, bezpečnosť, dôveryhodnosť, čitateľnosť ani to, či stránka odpovedá na otázku používateľa.

Nenahrádzajú ani úsudok. Stránka môže prejsť Core Web Vitals a stále byť nepríjemná. Zložitá aplikácia môže minúť prahovú hodnotu a pritom byť zodpovedne navrhnutá vzhľadom na svoje obmedzenia.

Berte LCP, INP a CLS ako dymové hlásiče. Keď sa spustia, skúmajte. Keď sú ticho, ďalej udržiavajte budovu.