Largest Contentful Paint (LCP) je v roce 2026 pořád ta nejproblematičtější metrika Core Web Vitals. A upřímně? Čísla z CrUX reportu za prosinec 2025 nejsou zrovna povzbudivá — dobrého LCP dosahuje jen 67,6 % webů. Na mobilech je to ještě horší, zhruba 62 %. LCP je prostě hlavní brzdou celkového skóre a má přímý dopad na pozice ve vyhledávání.
Takže pojďme na to. V tomhle průvodci si projdeme, co přesně LCP měří, proč váš web propadá, a hlavně — jak to opravit pomocí konkrétních technik s funkčními ukázkami kódu.
Co je Largest Contentful Paint a proč je tak důležitý
LCP měří dobu od zahájení načítání stránky do vykreslení největšího viditelného prvku obsahu ve viewportu. Tím prvkem může být obrázek, video (respektive jeho poster), textový blok nebo prvek s CSS pozadím.
Jednodušeji řečeno: LCP říká, jak rychle uživatel uvidí hlavní obsah stránky. To je celé.
Prahové hodnoty LCP
- ≤ 2,5 s — dobré skóre
- 2,5–4,0 s — potřebuje zlepšení
- > 4,0 s — špatné skóre
Google hodnotí LCP na 75. percentilu reálných návštěvníků. Co to znamená v praxi? Že 75 % vašich uživatelů musí mít LCP pod 2,5 sekundy, aby web prošel. A jsou to právě ti uživatelé na pomalých mobilních sítích — ti na 75. percentilu — kdo rozhodují o tom, jestli projdete, nebo ne.
Čtyři fáze LCP: kde přesně vzniká zpoždění
Google v roce 2025 začal v CrUX publikovat data o jednotlivých podfázích LCP. Tohle je důležité, protože každé zpoždění v kterékoli fázi se sčítá do celkového LCP. Bez pochopení těchto fází optimalizujete naslepo:
- Time to First Byte (TTFB) — doba od odeslání požadavku do přijetí prvního bajtu odpovědi serveru. Zahrnuje DNS, TCP handshake, TLS a zpracování na serveru.
- Resource Load Delay — doba od TTFB do okamžiku, kdy prohlížeč začne stahovat LCP zdroj (typicky obrázek). Čím déle trvá, než prohlížeč obrázek „objeví", tím déle čeká.
- Resource Load Duration — samotné stahování LCP zdroje. Tady záleží na velikosti souboru a rychlosti připojení.
- Element Render Delay — doba od dokončení stahování zdroje do jeho vykreslení na obrazovku. Typicky způsobeno blokováním hlavního vlákna JavaScriptem nebo render-blokujícím CSS.
Efektivní optimalizace LCP vyžaduje práci se všemi čtyřmi fázemi. Nestačí jen zmenšit obrázek — pokud server odpovídá 2 sekundy, žádná optimalizace na frontendu vás nezachrání.
Nejčastější příčiny špatného LCP
1. Velké a neoptimalizované obrázky
Obrázky jsou LCP prvkem na přibližně 42 % webových stránek a tvoří okolo 38 % celkové váhy stránky. Posílat 2400px originál, když se zobrazuje na šířce 800px? To je zbytečné plýtvání. Stejně tak používat JPEG místo moderních formátů WebP a AVIF.
2. Pozdní objevení LCP zdroje
Prohlížeč nemůže stáhnout obrázek, o kterém neví. Pokud je LCP obrázek načítaný přes JavaScript, CSS background-image nebo zanořený hluboko v komponentě, preload scanner ho prostě nevidí — a stahování začne pozdě.
3. Lazy loading hero obrázku
Tohle je chyba číslo jedna. Vážně.
Přidání loading="lazy" na hero obrázek říká prohlížeči, aby záměrně odložil jeho stahování, dokud se element neobjeví ve viewportu. Na optickém připojení to třeba znamená zpoždění jen 200 ms — ale na mobilní síti s vysokou latencí to klidně může být 3–4 sekundy navíc. A to je obrovský rozdíl.
4. Render-blokující zdroje
Velké CSS soubory a synchronní JavaScript v <head> blokují vykreslení celé stránky. Prohlížeč nemůže zobrazit žádný obsah, dokud nestáhne a nezpracuje všechny render-blokující zdroje. Ani jeden.
5. Pomalý TTFB
Pokud server odpovídá déle než 600 ms, je extrémně obtížné dosáhnout LCP pod 2,5 sekundy. Častými příčinami bývá pomalý hosting, chybějící caching, vícenásobná přesměrování nebo velká geografická vzdálenost serveru od uživatele (klasický problém pro české weby hostované v USA).
Strategie 1: Správné formáty a responzivní obrázky
Prvním krokem je zajistit, aby LCP obrázek měl minimální velikost bez ztráty kvality. V roce 2026 máme k dispozici tři formáty, které stojí za zvážení:
- AVIF — až o 50 % menší než JPEG při stejné kvalitě. Nejlepší komprese, ale pomalejší kódování (což u servírování nevadí, protože konvertujete jednou).
- WebP — o 25–34 % menší než JPEG. Plná podpora ve všech moderních prohlížečích.
- JPEG — jako fallback pro starší prohlížeče.
Ideální přístup je servírovat AVIF prohlížečům, které ho podporují, s fallbackem na WebP a JPEG:
<picture>
<source
type="image/avif"
srcset="
/img/hero-480.avif 480w,
/img/hero-800.avif 800w,
/img/hero-1200.avif 1200w"
sizes="(max-width: 768px) 100vw, (max-width: 1200px) 50vw, 1200px"
/>
<source
type="image/webp"
srcset="
/img/hero-480.webp 480w,
/img/hero-800.webp 800w,
/img/hero-1200.webp 1200w"
sizes="(max-width: 768px) 100vw, (max-width: 1200px) 50vw, 1200px"
/>
<img
src="/img/hero-800.jpg"
alt="Popis hero obrázku"
width="1200"
height="675"
loading="eager"
decoding="async"
fetchpriority="high"
/>
</picture>Atribut sizes říká prohlížeči, jak velký bude obrázek v layoutu, takže může zvolit správnou variantu z srcset ještě před stažením CSS. Bez správně nastaveného sizes prohlížeč stáhne zbytečně velký soubor — a to se bohužel děje překvapivě často.
Strategie 2: fetchpriority — řekněte prohlížeči, co je důležité
Prohlížeče přiřazují obrázkům ve výchozím nastavení nízkou prioritu, protože většina obrázků na stránce bývá pod záhybem. Hero obrázek je ale jiný případ — je to hlavní obsah stránky a měl by se stáhnout jako první.
Atribut fetchpriority="high" řekne prohlížeči, aby tento zdroj upřednostnil:
<img
src="/img/hero.webp"
alt="Hero obrázek"
width="1200"
height="675"
fetchpriority="high"
loading="eager"
/>A výsledky? Upřímně, poměrně působivé. Google ve vlastních testech zaznamenal zlepšení LCP z 2,6 s na 1,9 s pouhým přidáním fetchpriority="high". Tým Google Flights snížil LCP o 700 ms jedním HTML atributem. Etsy hlásí zlepšení LCP o 4 %. Jeden atribut, žádné vedlejší efekty — tohle je ten typ optimalizace, který se vyplatí vždycky zkusit.
Kdy fetchpriority nepoužívat
Nastavení vysoké priority na víc než jeden nebo dva obrázky je kontraproduktivní — ztrácí se efekt prioritizace. Obrázky pod záhybem nebo skryté slidery v karuselu naopak označte nízkou prioritou:
<!-- Aktivní slide karuselu -->
<img src="slide-1.jpg" fetchpriority="high" loading="eager" alt="Slide 1">
<!-- Skryté slidy -->
<img src="slide-2.jpg" fetchpriority="low" loading="lazy" alt="Slide 2">
<img src="slide-3.jpg" fetchpriority="low" loading="lazy" alt="Slide 3">Strategie 3: Preload pro včasné objevení LCP zdroje
Atribut fetchpriority zvyšuje prioritu stahování, ale nepomůže s objevitelností zdroje. Pokud prohlížeč o obrázku vůbec neví, nemůže ho prioritizovat. A tady přichází na řadu <link rel="preload">.
Kdy je preload nutný
- LCP obrázek je CSS
background-image - Obrázek je načítaný přes JavaScript (dynamicky vložený)
- Obrázek je v komponentě, kterou prohlížeč objeví pozdě
Kdy preload nepotřebujete
Pokud je obrázek přímo v HTML jako <img> element s fetchpriority="high", preload scanner ho objeví dostatečně brzy. Přidání preloadu v tomto případě nepřinese velké zlepšení a může dokonce vést ke zbytečnému duplikování požadavku.
Preload standardního obrázku
<head>
<link
rel="preload"
as="image"
href="/img/hero.webp"
fetchpriority="high"
/>
</head>Preload responzivního obrázku
Pro responzivní obrázky použijte atributy imagesrcset a imagesizes, aby prohlížeč vybral správnou variantu:
<link
rel="preload"
as="image"
href="/img/hero-800.webp"
imagesrcset="
/img/hero-480.webp 480w,
/img/hero-800.webp 800w,
/img/hero-1200.webp 1200w"
imagesizes="(max-width: 768px) 100vw, (max-width: 1200px) 50vw, 1200px"
fetchpriority="high"
/>Preload vs. fetchpriority — jaký je vlastně rozdíl?
- Preload — povinné stažení; pomáhá s včasným objevením zdroje, ale nestahuje s vyšší prioritou.
- fetchpriority — nápověda pro prohlížeč; nepomáhá s objevením, ale mění prioritu stahování.
- Kombinace obou — ideální pro CSS background obrázky a dynamicky vkládané zdroje.
Strategie 4: Eliminace render-blokujících zdrojů
I když se LCP zdroj stáhne rychle, nemůže se vykreslit, dokud prohlížeč nezpracuje všechny render-blokující zdroje. Dva hlavní viníci? CSS a JavaScript.
Kritické CSS inline
Extrahujte CSS potřebné pro obsah nad záhybem a vložte ho přímo do HTML. Zbytek CSS pak načtěte asynchronně:
<head>
<!-- Kritické CSS inline -->
<style>
.hero { position: relative; width: 100%; height: auto; }
.hero img { display: block; width: 100%; height: auto; }
/* ... další kritické styly ... */
</style>
<!-- Nekritické CSS asynchronně -->
<link
rel="preload"
href="/css/main.css"
as="style"
onload="this.onload=null;this.rel='stylesheet'"
/>
<noscript><link rel="stylesheet" href="/css/main.css"></noscript>
</head>Odložení nekritického JavaScriptu
Všechny skripty, které nejsou nezbytné pro první vykreslení, by měly mít atribut defer nebo async. Skripty třetích stran — analytika, chatovací widgety, reklamní skripty — by měly být načteny až po vykreslení hlavního obsahu:
<!-- Kritický skript s defer -->
<script src="/js/app.js" defer></script>
<!-- Analytika po načtení stránky -->
<script>
window.addEventListener('load', function() {
const script = document.createElement('script');
script.src = 'https://analytics.example.com/tracker.js';
document.body.appendChild(script);
});
</script>Strategie 5: Snížení TTFB
TTFB je základ všeho — nic na frontendu se nemůže stát dřív, než server pošle první bajt. Doporučená hodnota od Googlu je pod 800 ms, ale kompetitivní weby cílí na 100–300 ms pro dynamický obsah a pod 50 ms pro cachovaný obsah.
Podle mé zkušenosti je pomalý TTFB nejčastější příčinou špatného LCP u českých webů. Často narážím na servery, které odpovídají přes sekundu jen kvůli chybějícímu cachingu.
Praktické kroky ke snížení TTFB
- CDN — distribuce obsahu ze serverů blízkých uživatelům. Cloudflare, Fastly nebo AWS CloudFront dokáží dramaticky snížit latenci pro vzdálené uživatele.
- Full-page caching — Varnish, Redis nebo CDN edge caching mohou snížit TTFB z 2 sekund na pod 100 ms. Tohle je často ten největší quick win.
- Brotli komprese — o 15–25 % lepší komprese než Gzip, podporovaná všemi moderními prohlížeči.
- HTTP/2 a HTTP/3 — multiplexované připojení snižuje overhead opakovaných handshake.
- Early Hints (HTTP 103) — server může poslat nápovědy o důležitých zdrojích ještě před dokončením zpracování stránky.
# Příklad Nginx konfigurace pro optimální TTFB
server {
# Povolení Brotli komprese
brotli on;
brotli_comp_level 6;
brotli_types text/html text/css application/javascript image/svg+xml;
# Cache-Control pro statické zdroje
location ~* \.(jpg|jpeg|webp|avif|png|gif|ico|css|js|woff2)$ {
expires 1y;
add_header Cache-Control "public, immutable";
}
# Stale-while-revalidate pro HTML
location / {
add_header Cache-Control "public, max-age=60, stale-while-revalidate=86400";
proxy_pass http://backend;
}
}Strategie 6: Speculation Rules API pro okamžité načítání
Tady to začíná být opravdu zajímavé. Speculation Rules API je nejnovější technika pro dramatické zlepšení LCP při navigaci mezi stránkami. Prohlížeč může stránku předem stáhnout (prefetch) nebo kompletně předrenderovat (prerender) na pozadí — a při kliknutí ji zobrazit téměř okamžitě.
Rozdíl mezi prefetch a prerender
- Prefetch — stáhne HTML a kritické zdroje do cache. Zlepšuje především TTFB následné navigace.
- Prerender — stáhne a kompletně vykreslí stránku na pozadí. Navigace je prakticky okamžitá — LCP, TTFB i další metriky klesají na téměř nulu.
V testech bylo zaznamenáno snížení LCP až o 98 % při použití prerenderu. A to není překlep. Případová studie Ray-Ban ukázala nárůst konverzí na desktopu o 156 % díky spekulativnímu předběžnému načítání.
<script type="speculationrules">
{
"prerender": [
{
"where": {
"and": [
{ "href_matches": "/*" },
{ "not": { "href_matches": "/logout" } },
{ "not": { "href_matches": "/admin/*" } },
{ "not": { "selector_matches": "[data-no-prerender]" } }
]
},
"eagerness": "moderate"
}
],
"prefetch": [
{
"where": { "href_matches": "/*" },
"eagerness": "conservative"
}
]
}
</script>Úrovně eagerness
- conservative — typicky při kliknutí (mousedown). Minimální plýtvání zdroji.
- moderate — při najetí myší (hover). Dobrý kompromis mezi rychlostí a spotřebou dat.
- eager — při nejmenším náznaku zájmu. Nejvyšší rychlost, ale vyšší spotřeba zdrojů.
V Chrome 144 (2026) přichází experimentální režim prerender_until_script, který stránku předrenderuje včetně stažení všech subzdrojů a vykreslení „vizuální kostry", ale pozastaví provádění JavaScriptu až do skutečné navigace. Zajímavý kompromis — dostanete rychlost prerenderu bez plýtvání výpočetními zdroji.
Poznámka: Speculation Rules API je aktuálně podporováno pouze v prohlížečích na bázi Chromium. Ostatní prohlížeče pravidla ignorují, takže žádná negativní degradace nehrozí.
Strategie 7: Optimalizace v moderních frameworcích
Většina z vás pravděpodobně pracuje s nějakým frameworkem. Tady je, jak LCP optimalizaci implementovat v těch nejpopulárnějších.
Next.js
V Next.js použijte kombinaci atributů priority (přidá automaticky preload tag) a fetchPriority="high":
import Image from 'next/image';
export default function Hero() {
return (
<Image
src="/img/hero.jpg"
width={1200}
height={675}
priority
fetchPriority="high"
alt="Hero obrázek produktu"
sizes="(max-width: 768px) 100vw, 50vw"
/>
);
}Astro
Astro generuje statické HTML s minimálním JavaScriptem, což je pro LCP skvělý základ. Pro LCP obrázek použijte komponentu <Image> s atributem loading="eager":
---
import { Image } from 'astro:assets';
import heroImage from '../assets/hero.avif';
---
<Image
src={heroImage}
alt="Hero obrázek"
width={1200}
height={675}
loading="eager"
fetchpriority="high"
format="avif"
/>Nuxt.js / Vue
V Nuxt.js 3 s modulem @nuxt/image:
<NuxtImg
src="/img/hero.jpg"
width="1200"
height="675"
preload
loading="eager"
fetchpriority="high"
sizes="sm:100vw md:50vw lg:1200px"
format="webp"
/>Kompletní kontrolní seznam optimalizace LCP
Tohle je shrnutí všech technik v jednom seznamu. Doporučuju si ho projít bod po bodu — i zkušení vývojáři občas něco přehlédnou:
- Identifikujte LCP element — použijte Chrome DevTools, PageSpeed Insights nebo DebugBear.
- Zkontrolujte, zda nemá loading="lazy" — pokud ano, okamžitě odstraňte a přidejte
loading="eager". - Přidejte fetchpriority="high" — na LCP obrázek nebo jeho preload tag.
- Používejte moderní formáty — AVIF s fallbackem na WebP přes
<picture>element. - Servírujte responzivní obrázky — správné
srcsetasizesatributy. - Přidejte preload — pokud je LCP zdroj CSS background nebo dynamicky vkládaný.
- Nastavte explicitní rozměry — atributy
widthaheightna<img>zabraňují layout shiftu. - Inlinujte kritické CSS — vložte styly pro above-the-fold obsah přímo do HTML.
- Odložte nekritický JavaScript — použijte
defer,asyncnebo dynamické načítání. - Optimalizujte TTFB — CDN, caching, Brotli komprese, HTTP/3.
- Implementujte Speculation Rules — pro okamžité načítání při navigaci mezi stránkami.
- Měřte na reálných uživatelích — CrUX data, web-vitals knihovna nebo RUM nástroje.
Měření a monitoring LCP
Optimalizace bez měření je střelba naslepo. Používejte kombinaci laboratorních a field dat:
- Chrome DevTools Performance panel — záložka Performance, sekce Timings zobrazuje LCP marker.
- PageSpeed Insights — zobrazuje jak laboratorní (Lighthouse), tak reálná (CrUX) data.
- Search Console — report Core Web Vitals identifikuje stránky s problémovým LCP.
- web-vitals knihovna — pro sběr RUM dat přímo od vašich uživatelů.
import { onLCP } from 'web-vitals';
onLCP((metric) => {
console.log('LCP hodnota:', metric.value, 'ms');
console.log('LCP element:', metric.entries[0]?.element);
// Odeslání do analytiky
navigator.sendBeacon('/api/vitals', JSON.stringify({
name: metric.name,
value: metric.value,
id: metric.id,
navigationType: metric.navigationType,
}));
});Tip: Nastavte si alerty, když 75. percentil LCP překročí 2,0 s (to je 80 % prahu Googlu). Tak zachytíte regresi dříve, než se projeví v 28denním CrUX okně a ovlivní vaše pozice ve vyhledávání. Prevence je vždycky levnější než hasení požárů.
Časté otázky (FAQ)
Jaký je dobrý LCP čas a jak ho měřím?
Dobrý LCP je pod 2,5 sekundy na 75. percentilu reálných návštěvníků. Měřit ho můžete v laboratorních podmínkách pomocí Lighthouse nebo Chrome DevTools a na reálných uživatelích pomocí CrUX dat v PageSpeed Insights, Search Console nebo vlastního RUM řešení s knihovnou web-vitals. Vždy kombinujte oba přístupy — laboratorní data jsou skvělá pro diagnostiku, field data pro sledování skutečného stavu.
Proč mám špatné LCP, i když jsou obrázky optimalizované?
Protože LCP se skládá ze čtyř fází — TTFB, Resource Load Delay, Resource Load Duration a Element Render Delay. I s malými obrázky můžete mít špatné LCP kvůli pomalému serveru (vysoké TTFB), pozdnímu objevení obrázku (chybí preload), nebo render-blokujícímu CSS a JavaScriptu. Analyzujte LCP podfáze v Chrome DevTools nebo CrUX a zaměřte se na tu fázi, která zabírá nejvíc času.
Mám použít fetchpriority, preload, nebo obojí?
Záleží na situaci. Pokud je LCP obrázek přímo v HTML jako <img>, většinou stačí fetchpriority="high". Preload přidejte, pokud je obrázek CSS background, načítaný přes JavaScript, nebo pokud ho prohlížeč objevuje pozdě. Pro CSS background obrázky je ideální kombinace obojího — preload zajistí včasné objevení a fetchpriority zvýší prioritu stahování.
Jak Speculation Rules API pomáhá s LCP?
Speculation Rules API umožňuje prohlížeči předem stáhnout nebo kompletně předrenderovat stránku, na kterou uživatel pravděpodobně přejde. Při prerenderu je celá stránka připravená v paměti — když uživatel klikne na odkaz, zobrazí se prakticky okamžitě s LCP blížícím se nule. Prefetch zlepšuje hlavně TTFB následné navigace. API je aktuálně podporováno v Chromium prohlížečích a od WordPressu 6.8 je součástí jádra.
Jak zjistím, který element na stránce je LCP?
Nejrychlejší způsob: otevřete Chrome DevTools, přejděte na záložku Performance, zaznamenejte načítání stránky a v sekci Timings najdete LCP marker. Kliknutím na něj se zvýrazní příslušný DOM element. Můžete taky použít PageSpeed Insights, který LCP element zobrazí přímo v reportu, nebo knihovnu web-vitals, která v callbacku vrací referenci na LCP element.