Optimalizácia LCP 2026: Kompletný sprievo…

LCP (Largest Contentful Paint) je metrika, ktorá meria, ako rýchlo sa návštevníkovi zobrazí najväčší viditeľný prvok stránky. Od marca 2024 patrí medzi Core Web Vitals a Google ju zohľadňuje pri hodnotení vo vyhľadávaní. Aby ste získali zelené hodnotenie, LCP musí byť pod 2,5 sekundy u 75 % skutočných návštev. A áno, to "u 75 %" je tá zradná časť. V tomto sprievodcovi sa pozrieme, ako rozložiť LCP na štyri pod-časti, identifikovať úzke miesta a aplikovať techniky, ktoré v roku 2026 reálne fungujú v produkcii — nie len v Lighthouse na vašom MacBooku.

Čo presne meria LCP a prečo na ňom záleží

LCP sleduje čas vykreslenia najväčšieho prvku v aktuálnom viewporte — typicky hero obrázku, video plagátu alebo veľkého textového bloku. Prehliadač metriku aktualizuje dovtedy, kým používateľ neinteraguje so stránkou (klik, scroll, tap). Posledná hodnota pred prvou interakciou je tá, ktorú reportuje Chrome User Experience Report a používa ju Google Search.

Prahy podľa web.dev v roku 2026 zostávajú nezmenené:

Dobré: do 2,5 s
Vyžaduje zlepšenie: 2,5 – 4,0 s
Slabé: nad 4,0 s

Hodnotí sa 75. percentil — to znamená, že tri štvrtiny návštev musia byť pod prahom, vrátane mobilných zariadení a pomalých 4G sietí. A presne tu väčšina projektov zlyháva.

Štyri pod-časti LCP, ktoré musíte poznať

V roku 2022 Annie Sullivan z Chrome tímu rozdelila LCP na štyri merateľné segmenty. Tento model je stále základom diagnostiky aj v roku 2026:

Time to First Byte (TTFB) — od kliknutia po prvý bajt odpovede servera. Typicky 10 – 40 % LCP.
Resource Load Delay — od TTFB po začiatok sťahovania LCP zdroja. Čas, počas ktorého prehliadač ešte ani nevie, ktorý prvok bude LCP.
Resource Load Time — samotné sťahovanie obrázku, videa alebo CSS pre textový LCP.
Element Render Delay — od dokončenia sťahovania po vykreslenie pixelov na obrazovke.

Bez tohto rozdelenia jednoducho neviete, kam investovať čas. Optimalizácia obrázkov, keď je problém v TTFB, nezníži LCP ani o milisekundu — a pritom presne to vidím v audite snáď každého druhého projektu.

Ako presne zmerať LCP a jeho pod-časti

Web Vitals JS knižnica s atribútmi

Knižnica web-vitals verzie 4.x exportuje funkciu onLCP s rozšíreným atribučným režimom, ktorý vráti všetky štyri pod-časti:

import { onLCP } from 'web-vitals/attribution';

onLCP((metric) => {
  const a = metric.attribution;
  console.log({
    lcp: metric.value,
    element: a.element,
    url: a.url,
    timeToFirstByte: a.timeToFirstByte,
    resourceLoadDelay: a.resourceLoadDelay,
    resourceLoadDuration: a.resourceLoadDuration,
    elementRenderDelay: a.elementRenderDelay,
  });

  navigator.sendBeacon('/analytics/lcp', JSON.stringify({
    value: metric.value,
    parts: a,
    path: location.pathname,
  }));
});

Pošlite tieto dáta do vlastnej analytiky alebo do platformy ako SpeedCurve, DebugBear či Vercel Speed Insights. Po týždni zberu uvidíte celkom jasne, ktorá pod-časť dominuje na 75. percentile. (Tip: bez týchto reálnych dát budete len hádať.)

Chrome DevTools Performance panel

V Chrome 122+ je v Performance panely sekcia LCP breakdown, ktorá vizuálne ukáže všetky štyri pod-časti vrátane konkrétneho DOM elementu. Stačí spustiť nahrávanie, načítať stránku a kliknúť na záznam LCP v sekcii Timings.

PageSpeed Insights a CrUX

PSI v roku 2026 ukazuje LCP rozdelený na pod-časti priamo v sekcii Diagnostics. CrUX API navyše poskytuje agregované dáta zo skutočných používateľov:

curl -X POST "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com/",
    "metrics": ["largest_contentful_paint"],
    "formFactor": "PHONE"
  }'

Optimalizácia TTFB

Začnime od základu. Ak je TTFB nad 600 ms, LCP pravdepodobne nikdy nedosiahne zelené pásmo — bez ohľadu na to, ako rýchlo sa obrázok stiahne. Hľadanie úspor na obrázkoch je v takom prípade úplne márne.

Edge rendering a Early Hints

Statický HTML servírovaný z edge CDN (Cloudflare, Vercel, Netlify) má TTFB pod 100 ms v 95 % regiónov. Pre dynamický obsah použite HTTP 103 Early Hints, ktorý dovoľuje začať sťahovanie LCP zdroja ešte pred dokončením HTML odpovede:

HTTP/1.1 103 Early Hints
Link: </hero.avif>; rel=preload; as=image; fetchpriority=high
Link: </critical.css>; rel=preload; as=style

HTTP/1.1 200 OK
Content-Type: text/html
...

Cloudflare a Fastly podporujú Early Hints priamo z konfigurácie. Na Express serveri to vyzerá takto:

app.get('/', (req, res) => {
  res.writeEarlyHints({
    link: [
      '</hero.avif>; rel=preload; as=image; fetchpriority=high',
      '</critical.css>; rel=preload; as=style',
    ],
  });

  const html = renderApp(req);
  res.send(html);
});

Streaming SSR

Namiesto čakania na celé HTML pošlite klientovi <head> a hero sekciu okamžite, zvyšok streamujte. React 19, Next.js 15, SvelteKit a Astro 5 to podporujú natívne. V Next.js stačí použiť server komponenty s hranicami Suspense:

// app/page.tsx
import { Suspense } from 'react';

export default function Page() {
  return (
    <>
      <Hero />
      <Suspense fallback={<Skeleton />}>
        <SlowFeed />
      </Suspense>
    </>
  );
}

Eliminácia Resource Load Delay

Toto je typicky najväčšia časť LCP, ktorú vývojári prehliadajú. Prehliadač totiž objaví LCP obrázok až keď spracuje HTML — a ak je obrázok deklarovaný v komponente, ktorý sa hydratuje, môže to trvať aj sekundy. (Áno, doslova sekundy.)

fetchpriority="high" na LCP obrázku

Atribút fetchpriority je podporovaný vo všetkých moderných prehliadačoch od roku 2024 a dnes je to úplne štandardný nástroj:

<img
  src="/hero.avif"
  alt="Hero"
  width="1200"
  height="600"
  fetchpriority="high"
  decoding="async"
/>

Hovoríte tým prehliadaču, aby zdroj zaradil do TCP/QUIC fronty s vyššou prioritou než CSS, fonty a iné obrázky. Bez tohto atribútu Chrome obrázkom defaultne priraďuje "Low" prioritu, kým layout neprebehne — a vy potom v paneli Network krútite hlavou, prečo sa hero ťahá ako posledný.

Žiadne lazy loading na LCP obrázku

Nikdy, ale naozaj nikdy, nepoužívajte loading="lazy" na LCP obrázku. Pre obrázky pod fold ho používajte, pre hero obrázok nikdy:

<!-- ZLE: oddiali LCP -->
<img src="/hero.avif" loading="lazy" />

<!-- DOBRE -->
<img src="/hero.avif" fetchpriority="high" />
<img src="/below-fold.avif" loading="lazy" />

Preload pre dynamicky vložené LCP

Ak je LCP obrázok určený až za behu (napríklad responsívny hero zo CMS), pridajte explicitný <link rel="preload"> do HTML:

<link
  rel="preload"
  as="image"
  href="/hero-mobile.avif"
  imagesrcset="/hero-mobile.avif 480w, /hero-desktop.avif 1200w"
  imagesizes="100vw"
  fetchpriority="high"
/>

Skrátenie Resource Load Time

AVIF s WebP fallbackom

AVIF poskytuje o 30 – 50 % menšie súbory než WebP pri rovnakej vizuálnej kvalite. Od konca 2023 je podporovaný vo všetkých hlavných prehliadačoch, takže výhovorka "ešte to nie je všade" už neplatí:

<picture>
  <source type="image/avif" srcset="/hero.avif" />
  <source type="image/webp" srcset="/hero.webp" />
  <img src="/hero.jpg" alt="Hero" width="1200" height="600" fetchpriority="high" />
</picture>

Správne rozmery a srcset

Mobilný používateľ nepotrebuje 2400 px hero. Tie bajty navyše znamenajú extra sekundy na 4G — a u niekoho, kto sedí vo vlaku, aj viac:

<img
  src="/hero-800.avif"
  srcset="/hero-400.avif 400w,
          /hero-800.avif 800w,
          /hero-1200.avif 1200w,
          /hero-1600.avif 1600w"
  sizes="(max-width: 600px) 100vw, 1200px"
  alt="Hero"
  width="1200"
  height="600"
  fetchpriority="high"
/>

CDN s automatickou optimalizáciou

Cloudinary, Imgix, Bunny Optimizer a Vercel Image Optimization vracajú správny formát aj rozlíšenie na základe Accept hlavičky a parametra w:

<img src="https://cdn.example.com/hero.jpg?w=1200&auto=format&q=75" />

Element Render Delay

Posledná pod-časť. Aj keď je obrázok stiahnutý, prehliadač ho nemôže vykresliť, kým nemá hotový CSS layout a font, ktorý LCP element používa. Inak povedané: zbytočne ste optimalizovali predchádzajúce tri kroky, ak vás zabije čakanie na CSS.

Kritické CSS inline

Vložte CSS pre prvý viewport priamo do <head>. Nástroje ako Critters, Beasties alebo natívna podpora v Next.js a Nuxt to robia automaticky:

<head>
  <style>
    /* Iba CSS pre viewport — typicky 5-15 KB */
    .hero { display: flex; min-height: 60vh; background: #0a0a0a; }
    .hero h1 { font-size: clamp(2rem, 5vw, 4rem); }
  </style>
  <link rel="preload" href="/main.css" as="style"
        onload="this.rel='stylesheet'" />
</head>

font-display: optional pre textový LCP

Ak je váš LCP element nadpis, font ovplyvňuje render. Použite font-display: optional, ktoré zobrazí systémový font okamžite, ak sa webový font nestihne načítať za 100 ms:

@font-face {
  font-family: 'Inter';
  src: url('/fonts/inter-var.woff2') format('woff2-variations');
  font-display: optional;
}

Pre kritické fonty pridajte preload:

<link rel="preload" href="/fonts/inter-var.woff2"
      as="font" type="font/woff2" crossorigin>

Vyhýbajte sa JS závislým hero komponentom

Hero, ktorý vyžaduje React hydratáciu pred zobrazením? Antipattern. Renderujte ho ako čisté HTML/CSS server-side a JS interaktivitu pridajte progresívne. Klient na 5 rokov starom Androide vám za to poďakuje.

Reálne hodnoty z roku 2026

Podľa Web Almanac 2025 a CrUX dát z Q1 2026:

Iba 43 % webov má LCP v zelenom pásme na mobile.
Priemerný LCP element je obrázok v 72 % prípadov, text v 24 %, video v 4 %.
Weby s Early Hints zlepšili medián LCP o 180 – 350 ms.
Migrácia WebP → AVIF ušetrila priemerne 28 % bajtov a 200 – 400 ms LCP na 4G.
Weby používajúce fetchpriority="high" na hero obrázku majú LCP v priemere o 15 % nižší.

Kontrolný zoznam pre 2026

Zmerajte LCP cez web-vitals/attribution a identifikujte dominantnú pod-časť.
Ak TTFB > 600 ms — implementujte edge rendering alebo Early Hints.
Pridajte fetchpriority="high" na hero obrázok.
Nikdy nepoužívajte loading="lazy" na LCP elemente.
Servírujte AVIF s WebP/JPEG fallbackom.
Nastavte width, height a srcset pre správne rozmery.
Inline kritické CSS pre prvý viewport.
Pre webové fonty použite font-display: optional alebo swap s preloadom.
Otestujte na pomalej 4G a low-end zariadení (emulácia Moto G Power v DevTools).
Sledujte 75. percentil v CrUX, nie laboratórne hodnoty z lokálneho Lighthouse.

Najčastejšie otázky

Aký je rozdiel medzi LCP a FCP?

FCP (First Contentful Paint) meria vykreslenie akéhokoľvek prvého obsahu — môže to byť aj loading spinner alebo malý text. LCP meria až najväčší viditeľný prvok, ktorý reprezentuje skutočne dôležitý obsah stránky. FCP môže byť rýchly, zatiaľ čo LCP poriadne zaostáva.

Prečo má môj Lighthouse LCP 1,5 s, ale CrUX ukazuje 3,8 s?

Lighthouse je laboratórny test na vašom zariadení v ideálnych podmienkach. CrUX zbiera dáta od skutočných používateľov po celom svete na rôznych zariadeniach a sieťach. Vždy sa rozhodujte podľa CrUX (75. percentil), nie podľa Lighthouse. Úprimne, koľkokrát som túto pascu už videl v praxi — neuveriteľné.

Môže mať stránka viacero LCP kandidátov?

Áno. Prehliadač počas načítania mení LCP kandidáta zakaždým, keď sa zobrazí väčší prvok. Posledný kandidát pred prvou interakciou používateľa je reportovaný ako finálny LCP. Preto pri analýze pozrite element, ktorý bol LCP pri pohľade používateľa, nie počas vývoja.

Ovplyvňuje LCP iba mobilné výsledky vyhľadávania?

Nie. Google používa Core Web Vitals ako rankingový signál pre desktop aj mobil od augusta 2022. Mobilný LCP je však zvyčajne horší, pretože používatelia majú pomalšiu sieť a slabší procesor — preto sa naň zameriavajte primárne.

Pomôže HTTP/3 znížiť LCP?

Áno, ale zriedka výrazne. HTTP/3 (QUIC) eliminuje head-of-line blocking a má rýchlejší TLS handshake — typicky ušetríte 50 – 150 ms na TTFB pri stratových sieťach. Pre weby s mnohými zdrojmi z jednej domény je benefit väčší. Aktivujte ho na CDN, ak je to jednoduché tlačidlo, ale nečakajte zázraky.

Záver

LCP nie je o jednej veci — je to reťazec štyroch nezávislých krokov a každý z nich môže byť úzkym miestom. Začnite meraním cez web-vitals/attribution, identifikujte dominantnú pod-časť a aplikujte techniky špecificky pre ňu. V roku 2026 máte k dispozícii Early Hints, fetchpriority, AVIF, streaming SSR a edge rendering — kombináciu, ktorá pred troma rokmi jednoducho neexistovala. Webový výkon nie je raketová veda, ale vyžaduje disciplínu a meranie tam, kde to skutočne počíta — u vašich používateľov, nie na vašom MacBooku.