Core Web Vitals: LCP, INP a CLS vysvetlené

Core Web Vitals sú metriky, ktoré prepájajú technické SEO so skutočnou používateľskou skúsenosťou. Abstraktné pojmy z oblasti výkonu prevádzajú na tri merateľné hodnoty, ktoré Google zbiera priamo z prehliadačov skutočných návštevníkov. Tento článok podrobne vysvetľuje LCP, INP a CLS, realisticky hodnotí ich váhu ako rankingového signálu a ukazuje, ako tieto metriky cielene zlepšiť v modernom stacku s Next.js, Edge/CDN a HTTP/3. Dôraz je na mobilnom používaní, cez ktoré napríklad v Rakúsku prebieha väčšina prístupov na internet.

Prečo sú Core Web Vitals dôležité pre technické SEO

Core Web Vitals sú tá časť page experience, ktorú Google presadzuje a používa vo svojich rankingových systémoch. Google v oficiálnej dokumentácii jasne uvádza, že neexistuje jediný signál page experience, Core Web Vitals však rankingové systémy využívajú a dobrá page experience môže pri vyhľadávacích dopytoch s veľkým množstvom užitočného obsahu prispieť k úspechu vo vyhľadávaní (Google Search Central). Tieto tri metriky teda nie sú hlavným rankingovým faktorom, ale spoľahlivým signálom kvality, ktorý rozhoduje najmä vtedy, keď si konkuruje viacero obsahovo rovnocenných výsledkov.

Prax ukazuje, koľko priestoru na zlepšenie ešte zostáva. Podľa Web Almanac 2024 spĺňa všetky tri Core Web Vitals len 43 percent mobilných originov, na desktope je to 54 percent (HTTP Archive, Web Almanac 2024). Ak tu pracuješ dôsledne, odlíšiš sa od viac ako polovice mobilného webu. Pre Rakúsko je to obzvlášť dôležité, pretože používanie internetu je tam silne mobilné: v júni 2024 tam prebehlo 81,5 percenta prístupov na internet cez mobilné zariadenia. Veľká časť z nich pripadla na aplikácie. Cez mobilný web išlo 31,6 percenta všetkých prístupov (Statista, Österreichische Webanalyse). Pre Core Web Vitals sa počíta len podiel prehliadačov a aj ten je z veľkej časti mobilný.

Tri metriky a ich prahové hodnoty

Google rozdeľuje hodnotenie do kategórií good, needs improvement a poor a meria vždy na 75. percentile zobrazení stránky, oddelene pre mobil a desktop. Oficiálne prahové hodnoty pre good sú: LCP 2,5 sekundy alebo menej, INP 200 milisekúnd alebo menej a CLS 0,1 alebo menej (web.dev). 75. percentil konkrétne znamená, že prahovú hodnotu musia dosiahnuť tri zo štyroch zobrazení, najhoršia štvrtina sa nepočíta. Stránka teda Core Web Vital splní až vtedy, keď je spoľahlivo rýchla, nie iba v ideálnom prípade.

• Largest Contentful Paint (LCP): meria, kedy sa vo viewporte vykreslí najväčší viditeľný prvok. Zastupuje vnímanú rýchlosť načítania.
• Interaction to Next Paint (INP): meria latenciu medzi interakciou používateľa a najbližšou viditeľnou aktualizáciou obrazu, a to počas celej relácie.
• Cumulative Layout Shift (CLS): meria najväčší zhluk neočakávaných posunov layoutu počas celej životnosti stránky, teda to, ako stabilne obsah zostáva na mieste (web.dev).

Na úrovni jednotlivých metrík je obraz v mobilnom segmente nejednotný. V roku 2024 dosiahlo dobré LCP 59 percent mobilných stránok, dobré INP 74 percent a dobré CLS 79 percent (Web Almanac 2024). LCP je teda na mobilných zariadeniach najčastejšie nesplnenou z troch metrík.

LCP podrobne: optimalizácia vnímaného načítania

Pri LCP ide takmer vždy o obrázok. 73,3 percenta mobilných stránok má ako LCP prvok obrázok (Web Almanac 2024). LCP obrázok je preto najdôležitejšou jednotlivou pákou optimalizácie. Typické príčiny pomalého LCP ležia v troch oblastiach: vysoký čas odozvy servera (TTFB), zdroje blokujúce vykresľovanie, napríklad CSS a JavaScript v kritickej ceste, a samotný čas načítania LCP zdroja.

Najúčinnejšie protiopatrenia mieria presne na tieto miesta:

• Riaď prioritu: LCP obrázok označ atribútom fetchpriority="high" a podľa potreby si ho vyžiadaj vopred cez <link rel="preload">, aby ho prehliadač nezaradil za menej dôležité zdroje.
• LCP obrázok nikdy nenačítavaj cez lazy loading: Ide o rozšírený anti-pattern. 16 percent mobilných stránok načítava svoj LCP obrázok cez lazy loading, 9,5 percenta dokonca cez natívne loading="lazy" (Web Almanac 2024). LCP prvok patrí nad zlom stránky a musí sa načítať okamžite (eager).
• Používaj moderné formáty obrázkov: AVIF a WebP oproti JPEG výrazne zmenšujú veľkosť súborov, a tým skracujú čas načítania zdroja.
• Znižuj TTFB cez Edge/CDN: Doručovanie z uzla CDN blízko používateľa a moderné prenosové protokoly skracujú čas odozvy servera ešte predtým, ako sa vôbec vykreslí prvý pixel.

INP podrobne: zabezpečenie interaktivity

INP nahradil FID ako Core Web Vital 12. marca 2024 a zároveň ho Search Console začala zobrazovať namiesto FID (web.dev). Nešlo o kozmetickú zmenu: FID meral len oneskorenie prvej interakcie, INP hodnotí všetky interakcie počas relácie a je výrazne prísnejší. Presne to sa prejavuje v číslach: s FID by v roku 2024 malo dobré CWV ešte 48 percent mobilných stránok, s INP je to len 43 percent (Web Almanac 2024).

INP sa skladá z troch fáz: Input Delay (čakanie, kým sa môže spustiť event handler), Processing Time (vykonanie handlera) a Presentation Delay (čas do ďalšej snímky). Zďaleka najčastejšou príčinou zlého INP je blokujúci JavaScript, ktorý zaberá hlavné vlákno (main thread) a hromadí interakcie. Z toho vyplývajú tri páky, ktorým sa podrobne venuje článok Optimalizácia INP:

• Rozdeľ dlhé úlohy (task splitting): Veľké úlohy JavaScriptu rozlož na menšie časti a medzi nimi vráť prehliadaču kontrolu, napríklad cez scheduler.yield() alebo odloženie, aby vstupy nemuseli čakať.
• Obmedz frekvenciu udalostí (debouncing): Často spúšťané handlery, napríklad udalosti scroll alebo input, priškrť, aby sa náročná logika nespúšťala pri každom pixeli.
• Presuň prácu mimo hlavného vlákna (Web Workers): Výpočtovo náročnú prácu, ktorá nesúvisí s UI, presuň do Web Workera, aby hlavné vlákno zostalo voľné.

CLS podrobne: udržanie vizuálnej stability

CLS hodnotí vizuálnu stabilitu stránky: penalizuje obsah, ktorý po prvom vykreslení ešte poskakuje. Príčiny sú dobre známe: obrázky a iframy bez pevných rozmerov, dynamicky dočítaný obsah nad existujúcim obsahom, neskoro načítané webové písma so skokom layoutu a reklamné plochy bez rezervovaného miesta. Protiopatrenia sú vo všetkých prípadoch preventívne:

• Zadaj rozmery: Pri obrázkoch a videách vždy nastav width a height alebo aspect-ratio, aby prehliadač vyhradil miesto ešte pred načítaním.
• Vyhraď miesto pre dynamické prvky: Pre reklamy, embedy a dočítané bannery naplánuj v layoute pevné sloty, namiesto toho, aby si ich vkladal do toku obsahu.
• Zmierni výmenu písma: Pomocou font-display a vopred načítaných písiem minimalizuj preformátovanie textu pri výmene fontu.

So 79 percentami dobrých hodnôt na mobilných zariadeniach je CLS najlepšie zvládnutou z troch metrík (Web Almanac 2024). Dôvodom je, že protiopatrenia sú technicky jednoduché a stačí ich zaviesť raz.

Osvedčené postupy: CWV v stacku s Next.js a Edge

V Next.js je veľa optimalizácií CWV zabudovaných už v stavebných blokoch frameworku, musíš ich však vedome používať. next/image vynucuje rozmery a doručuje moderné formáty. Pri najdôležitejšom obrázku zvyšuje fetchPriority="high" prioritu načítania, čo priamo prispieva k LCP. Do Next.js 14 túto hodnotu nastavoval automaticky atribút priority. Od Next.js 15 zabezpečuje priority už len preload a eager loading, fetchPriority="high" musíš nastaviť sám (Next.js, Pull Request #67351). Od Next.js 16 je priority označený ako zastaraný v prospech preload a dokumentácia Next.js vo väčšine prípadov odporúča fetchPriority="high" alebo loading="eager". next/font načítava písma lokálne a z vlastného hostingu, a tým predchádza skoku layoutu spôsobenému písmom, ktorý zhoršuje CLS. Streaming cez SSR a React Server Components znižuje množstvo JavaScriptu odoslaného klientovi, čo zmierňuje hlavnú príčinu zlého INP.

Najkritickejším miestom v App Routeri je hydratácia. Každý interaktívny klientsky komponent sa musí v prehliadači hydratovať a príliš veľa klientskeho JavaScriptu vytvára presne tie dlhé úlohy, ktoré zhoršujú INP. V praxi to znamená: ponechaj čo najviac častí ako Server Components, interaktivitu obmedz na malé klientske ostrovčeky a ťažké komponenty dočítavaj cielene.

Technický základ tieto efekty ešte posilňuje. Na webe sa dnes cez CDN doručuje 54 percent z viac ako 1,3 miliardy požiadaviek, kým HTTP/3 je síce dostupné približne na 30 percentách stránok, no skutočne sa využíva len pri 7 až 9 percentách prvých zobrazení stránky (Web Almanac 2024, HTTP). Edge caching a HTTP/3 znižujú TTFB, a tým aj štartovací bod LCP, bez toho, aby si musel meniť kód frontendu.

Rýchlejšie a čisto cachované doručovanie navyše pomáha crawl budgetu a AI crawlerom, ktoré web sťahujú v čoraz väčšom rozsahu: Googlebot od mája 2024 do mája 2025 vzrástol o 96 percent a drží približne 50-percentný podiel medzi crawlermi, GPTBot stúpol z 2,2 na 7,7 percenta (Cloudflare). Výkonná, predvídateľne doručovaná stránka je tak výhodou aj pre Generative Engine Optimization (GEO).

Časté chyby pri optimalizácii CWV

• Považovať lab hodnoty za realitu: Zelené skóre v Lighthouse v laboratóriu nehovorí nič o tom, čo Google hodnotí. Rozhodujúci je 75. percentil skutočných používateľov.
• Načítavať LCP obrázok cez lazy loading: Najčastejšia chyba, ktorou si pri LCP uškodíš sám. Prvok nad zlomom stránky sa nikdy nesmie načítavať oneskorene.
• Zamieňať INP s FID: Ak ešte optimalizuješ podľa FID, meriaš nesprávnu veličinu. INP je od marca 2024 jediná relevantná metrika interaktivity.
• Kontrolovať CLS len na začiatku stránky: Skok layoutu často nastane až pri scrollovaní alebo pri neskorom vkladaní obsahu. CLS sa meria počas celého životného cyklu stránky.
• Testovať len desktop: Google hodnotí mobil a desktop oddelene a na mobile spĺňa všetky tri hodnoty výrazne menej originov (43 oproti 54 percentám, Web Almanac 2024). Testy musia prebiehať na mobile so spomaleným CPU a sieťou.

Meranie: lab vs. field a správne nástroje

Najdôležitejšie je rozlišovať medzi laboratórnymi a terénnymi dátami. Laboratórne dáta (lab) vznikajú v kontrolovanom prostredí, napríklad v Lighthouse, a hodia sa na debugging a reprodukovateľné porovnania. Do rankingu sa však nezapočítavajú. Terénne dáta (field) pochádzajú od skutočných používateľov a vyhodnocujú sa na 75. percentile (web.dev). Do hodnotenia sa počítajú len tieto dáta skutočných používateľov.

• Chrome UX Report (CrUX): Oficiálny zdroj terénnych dát, agregovaný od skutočných používateľov Chromu. Je základom reportu v Search Console a PageSpeed Insights.
• PageSpeed Insights: Kombinuje terénne dáta z CrUX navrchu s laboratórnym behom Lighthouse pod nimi. Ideálny nástroj, ak chceš vidieť reálny stav a technickú príčinu vedľa seba.
• Report CWV v Search Console: Zoskupuje URL podľa kategórií good, needs improvement a poor na základe terénnych dát a ukazuje vývoj v čase pre celú property.
• RUM a web-vitals.js: Vlastné meranie skutočných používateľov priamo v kóde, napríklad cez knižnicu web-vitals.js, prináša priebežné terénne dáta a podrobnú diagnostiku, aj pre nástroje ako DebugBear.

Ak dôsledne oddeľuješ lab a field, vyhneš sa najčastejšej chybe pri interpretácii: považovať dobrý laboratórny výsledok za splnený Core Web Vital.

CWV ako rankingový signál a business case

Realistické očakávanie znie: Core Web Vitals nenahrádzajú relevanciu ani kvalitný obsah. Google výslovne uvádza, že neexistuje jediný signál a vždy chce zobraziť najrelevantnejšiu odpoveď, aj pri neoptimálnej page experience, dobrá page experience však môže pri vyhľadávacích dopytoch s veľkým množstvom užitočného obsahu rozhodnúť (Google Search Central). CWV teda pôsobia ako zosilňovač a tie-breaker, nie ako skratka popri slabom obsahu.

Silnejšou pákou je často konverzia. Prípadová štúdia redBus, ktorú zdokumentoval Google, ukazuje, že cielená optimalizácia INP zvýšila tržby o 7 percent, pričom samotné INP sa zlepšilo o 72 percent, okrem iného vďaka debounced scroll handlerom a menšiemu počtu volaní API (web.dev, redBus). Tieto čísla pochádzajú z medzinárodného prípadu, mechanizmus je však prenosný: rýchlejšie interakcie znižujú počet opustení a zvyšujú mieru konverzie. V rakúskom kontexte, kde väčšina prístupov na internet prebieha cez mobilné zariadenia (Statista), zasiahne každé zlepšenie mobilného INP alebo LCP priamo veľkú časť návštevníkov. Business case pre CWV je preto menej argumentom pre SEO a viac argumentom pre tržby s vedľajším prínosom pre SEO.

Ďalšie zdroje

Core Web Vitals sú najúčinnejšie, keď sú zasadené do celého technického SEO stacku. LCP závisí od TTFB, a tým od Edge/CDN cachingu a HTTP/3, INP od stratégie JavaScriptu a vykresľovania a všetky tri profitujú z čistej architektúry Next.js s minimom klientskeho JavaScriptu. Ak sem investuješ, zlepšíš zároveň doručovanie klasickým crawlerom aj AI crawlerom, a tým aj viditeľnosť v GEO. Tému si môžeš prehĺbiť v článkoch o JavaScript SEO a renderovaní, HTTP/3 a výkonnostnej infraštruktúre, Edge SEO na úrovni CDN, CDN a umiestnení servera a o SEO architektúre Next.js.