Optimalizácia LCP: najťažší Core Web Vital

Largest Contentful Paint (LCP) je metrika Core Web Vitals, na ktorej zlyháva najviac webov. Meria, ako dlho trvá, kým sa vo viewporte vykreslí najväčší viditeľný blok obsahu. Tento článok vysvetľuje, ako LCP presne funguje, z čoho sa skladá čas načítania, ako LCP technicky optimalizuješ a prečo táto metrika priamo ovplyvňuje konverzie a viditeľnosť B2B firiem v regióne DACH.

Prečo je LCP dôležité pre firmy

LCP je jedna z troch Core Web Vitals, ktorými Google hodnotí používateľskú skúsenosť na stránke. Z týchto troch metrík je LCP najnáročnejšia. Podľa HTTP Archive Web Almanac 2025 dosahuje dobrú hodnotu LCP 62 percent mobilných a 74 percent desktopových stránok (medzinárodný prieskum, údaje CrUX z júla 2025). Na porovnanie: INP má na mobilných zariadeniach 77 percent dobrých hodnôt a CLS 81 percent. LCP je teda limitujúci faktor: práve táto metrika najčastejšie rozhoduje o tom, či stránka v teste Core Web Vitals obstojí. Celkovo spĺňa všetky tri Core Web Vitals len 48 percent mobilných a 56 percent desktopových originov (medzinárodný prieskum).

Pre rakúsky trh je mobilný výkon obzvlášť dôležitý. V septembri 2025 pripadlo približne 44,4 percenta všetkých zobrazení internetových stránok v Rakúsku na mobilné zariadenia (Rakúsko, údaje StatCounter bez tabletov). Mobilní používatelia majú podľa Web Almanac takmer dvakrát častejšie zlé hodnoty LCP ako používatelia na desktope, konkrétne 13 percent oproti 7 percentám (medzinárodný prieskum). Kto v Rakúsku obsluhuje takmer polovicu svojej návštevnosti cez mobil, optimalizuje LCP presne tam, kde je slabina najväčšia.

Obchodný prínos sa dá zmerať. A/B štúdia Vodafonu, ktorú zdokumentoval Google, ukazuje, že o 31 percent lepšie LCP viedlo k nárastu predajov o 8 percent, k zlepšeniu pomeru lead-to-visit o 15 percent a pomeru cart-to-visit o 11 percent (medzinárodná štúdia). Vplyv rýchlosti potvrdzuje aj prieskum Deloitte Digital a Fifty-Five pre Google: v maloobchode zvýšilo už o 0,1 sekundy rýchlejšie mobilné načítanie mieru konverzie o 8,4 percenta a priemernú hodnotu objednávky o 9,2 percenta (medzinárodná štúdia). Pre ľudí, ktorí v B2B firmách rozhodujú, LCP preto priamo ovplyvňuje obrat a kvalitu leadov. Pri tesných rozhodnutiach o rankingu môže metrika navyše rozhodnúť medzi inak rovnocennými výsledkami.

Ako LCP funguje: prahové hodnoty a subčasti

LCP meria okamih, keď sa vo viewporte vykreslí najväčší viditeľný blok obsahu. Meria sa od začiatku načítania stránky. Ako LCP element prichádzajú do úvahy typicky hero obrázky, veľké textové bloky alebo videá. V praxi dominujú obrázky: u 85,3 percenta desktopových a 76 percent mobilných stránok je LCP elementom obrázok (medzinárodný prieskum). Zvyšok tvoria textové LCP elementy, na mobilných zariadeniach ich je 23,7 percenta, teda o niečo viac ako na desktope.

Google definuje tri pásma hodnôt, merané na 75. percentile skutočných používateľských dát:

• Dobrá: pod 2,5 sekundy. Táto hodnota by mala byť cieľom každej optimalizácie.
• Treba zlepšiť: medzi 2,5 a 4,0 sekundami. Tu je potrebné konať.
• Zlá: nad 4,0 sekundy. V tomto pásme používateľská skúsenosť výrazne trpí.

75. percentil znamená: prahovú hodnotu musí dosiahnuť 75 percent skutočných načítaní stránky. Dobrá laboratórna hodnota na rýchlom vývojárskom počítači preto nestačí, ak pomalšie zariadenia a pripojenia posúvajú percentil nahor.

Ak chceš LCP cielene optimalizovať, musíš pochopiť, z čoho sa čas skladá. Google rozdeľuje LCP na štyri subčasti:

• Time to First Byte (TTFB): čas do chvíle, keď server doručí prvý bajt odpovede. Zahŕňa DNS, nadviazanie spojenia a spracovanie na strane servera.
• Resource Load Delay: čas medzi TTFB a začiatkom načítania LCP zdroja. Tu sa stráca čas, keď prehliadač objaví LCP obrázok až neskoro.
• Resource Load Duration: samotný čas načítania LCP zdroja, teda ako dlho trvá stiahnutie obrázka alebo písma.
• Element Render Delay: čas medzi úplným načítaním zdroja a jeho skutočným vykreslením, často blokovaný JavaScriptom alebo CSS.

Toto rozdelenie je kľúčom k diagnostike. Pomalý LCP obrázok si vyžaduje iné opatrenie ako pomalý server alebo render-blokujúci JavaScript.

Osvedčené postupy: ako cielene optimalizovať LCP

Najúčinnejšie optimalizácie sa zameriavajú na štyri subčasti. Najväčší účinok majú v praxi tieto opatrenia:

• Skrátiť TTFB a odozvu servera: Pomalý server je často najväčšia samostatná položka. Server-side rendering, dobre nastavený caching a CDN s edge uzlami skracujú cestu dát. HTTP/3 (QUIC) a kompresia Brotli prenos ešte zrýchľujú. Pre cieľové skupiny v DACH a v Rakúsku sa oplatí hosting alebo CDN edge s krátkou cestou k rakúskym používateľom, napríklad uzol vo Viedni alebo vo Frankfurte.
• Správne doručiť LCP obrázok: Moderné formáty ako WebP a AVIF výrazne zmenšujú súbory oproti JPEG pri rovnakej kvalite. Napriek tomu je JPEG podľa Web Almanac s približne 57 percentami stále najčastejším formátom LCP obrázkov, WebP nasleduje s 11 percentami a AVIF dosahuje len 0,7 percenta (medzinárodný prieskum). Tu teda leží nevyužitý potenciál. Dodávaj responzívne varianty cez srcset a sizes, definuj správne rozmery obrázka a nastav pre LCP obrázok fetchpriority="high". Preload potrebuješ len vtedy, keď prehliadač nenájde obrázok priamo v HTML, napríklad pri obrázku na pozadí v CSS.
• Vyhnúť sa lazy loadingu LCP obrázka: LCP obrázok sa nikdy nesmie načítavať oneskorene. Podľa Web Almanac približne 16 až 17 percent stránok načítava svoj LCP obrázok lazy (medzinárodný prieskum) a stráca tak cenný čas. loading="lazy" patrí k obrázkom pod viditeľnou oblasťou, nie k LCP elementu.
• Odstrániť blokovanie vykresľovania: Kritické CSS by sa malo doručiť inline, zvyšok oneskorene. JavaScript sa načítava s atribútom defer alebo async, aby neblokoval vykresľovanie. Webové fonty dostanú font-display: swap a preload, aby textové bloky nečakali na písmo.

Časté chyby pri optimalizácii LCP

Pri optimalizácii sa opakujú určité vzorce, ktoré stoja čas načítania:

• Lazy loading LCP obrázka: Najčastejšia chyba. Plošné loading="lazy" na všetkých obrázkoch zasiahne aj hero obrázok a zbytočne predĺži Resource Load Delay.
• Optimalizovať len laboratórne hodnoty: Kto sleduje iba hodnoty z Lighthouse, optimalizuje pre syntetický testovací beh, nie pre skutočných používateľov. 75. percentil terénnych dát môže byť výrazne horší.
• Ignorovať TTFB: Mnohé tímy optimalizujú obrázky, hoci skutočnou brzdou je server. Bez pohľadu na subčasti sa pracuje na nesprávnom mieste.
• Ponechať zastarané formáty obrázkov: Vysoký podiel JPEG ukazuje, že moderné formáty sa používajú zriedka. Kto zostane pri JPEG, prichádza o jednoduchý nárast efektivity.
• Podceniť hydratáciu JavaScriptu: V moderných frameworkoch môže byť LCP element úplne načítaný, no kvôli hydratácii sa vykreslí oneskorene. Element Render Delay rastie bez toho, aby za to mohol obrázok alebo server.

LCP v architektúre Next.js

Next.js ponúka viacero mechanizmov, ktoré priamo zlepšujú LCP. Komponent next/image automaticky dodáva moderné formáty, správne rozmery a responzívne veľkosti. Pre LCP obrázok nastav od Next.js 16 loading="eager", aby sa nenačítaval lazy, a fetchPriority="high". Doterajší prop priority je od Next.js 16 zastaraný a nahradil ho prop preload. Podľa dokumentácie však preload potrebuješ zriedka: vo väčšine prípadov stačí loading="eager" alebo fetchPriority="high" a preload sa na obrázku nemá kombinovať s týmito nastaveniami. V Next.js 15 a starších zostáva správnou cestou priority. Takto by sa mal prioritizovať práve jeden obrázok na stránke, a to LCP element.

App Router so Server Components a streamingovým SSR vykresľuje kritický obsah na strane servera a posiela ho prehliadaču čo najskôr. To skracuje Resource Load Delay aj Element Render Delay, pretože LCP obsah nevzniká až na strane klienta. Dôležité je neschovávať LCP element za hydratáciu na strane klienta. Obsah vykreslený ako Server Component je k dispozícii okamžite. Ak sa však presunie do Client Component s náročnou hydratáciou, oneskorenie vykreslenia rastie.

Metriky a meranie: terénne verzus laboratórne dáta

LCP sa meria dvoma spôsobmi a potrebné sú oba. Terénne dáta pochádzajú od skutočných používateľov a zobrazujú realitu. Zdrojmi sú Chrome User Experience Report (CrUX), PageSpeed Insights a Google Search Console. Tieto dáta určujú oficiálny 75. percentil, a teda aj to, či stránka testom prejde. Laboratórne dáta vznikajú synteticky za kontrolovaných podmienok, napríklad v Lighthouse alebo v lokálnych nástrojoch. Sú reprodukovateľné a hodia sa na testovanie zmien pred nasadením a na izoláciu jednotlivých príčin.

Rozhodujúci bod: oba typy sa dopĺňajú. Laboratórne dáta ukazujú, v čom je problém, terénne dáta ukazujú, či sa skutočne týka používateľov. Optimalizácia je úspešná až vtedy, keď sa prejaví v terénnych dátach.

Na priebežnú kontrolu sa odporúča Real User Monitoring (RUM). Oficiálna knižnica web-vitals zaznamenáva LCP priamo v prehliadači skutočných používateľov a posiela hodnoty do analytického nástroja. Vďaka tomu sa dajú nastaviť upozornenia a regresie po nasadeniach odhaliť včas. Bez takého monitoringu si zhoršenie LCP často všimneš až vtedy, keď už trpia rankingy alebo konverzie. Pevné miesto v procese nasadenia, napríklad automatická kontrola v Lighthouse plus porovnanie s RUM, chráni pred plíživými regresiami.

LCP, AI crawlery a GEO: správne zaradenie

Rýchly server-side rendering pomáha používateľom aj crawlerom. AI crawlery a klasické boty vyhľadávačov profitujú, keď sa obsah doručuje na strane servera a bez dlhých závislostí od JavaScriptu. Tá istá architektúra, ktorá zlepšuje LCP, teda SSR, rýchly TTFB a málo render-blokujúceho JavaScriptu, robí obsah spoľahlivo dostupným aj pre AI crawlery.

Dôležité je rozlíšenie. LCP je metrika výkonu pre používateľskú skúsenosť, nie priamy GEO faktor. O Generative Engine Optimization rozhoduje obsah, štruktúra a citovateľnosť, nie čas načítania hero obrázka. LCP pomáha nepriamo tým, že rýchly server-side rendering uľahčuje doručovanie obsahu crawlerom. Žiadne GEO opatrenie však nenahrádza. Kto optimalizuje LCP, zlepšuje dostupnosť, nie obsahovú relevanciu pre odpovede AI.

Ďalšie kroky a záver

LCP je metrika Core Web Vitals s najväčším potenciálom optimalizácie a najpriamejším vzťahom k biznisu. Kto dosiahne cieľ pod 2,5 sekundy na 75. percentile terénnych dát, zlepší používateľskú skúsenosť, konverzie, mieru odchodov a šance pri tesných rozhodnutiach o rankingu. Cesta k tomu vedie cez štyri subčasti: rýchly server, včas objavený a moderne doručený LCP obrázok, žiadny lazy loading hero obrázka a vykresľovanie bez blokujúceho CSS alebo JavaScriptu.

Rozumné ďalšie kroky sú meranie aktuálneho LCP v PageSpeed Insights a Search Console, identifikácia LCP elementu a jeho subčastí a nastavenie Real User Monitoringu na trvalú kontrolu. Na rakúskom trhu s vysokým podielom mobilnej návštevnosti sa oplatí zamerať najmä na mobilné LCP, pretože práve tam sú najväčšie nedostatky.