LCP Optimalizace: 7 Ověřených Technik pro Web pod 2.5 Sekundy

Minulý rok jsem analyzovala e-shop s nábytkem. Majitel investoval přes 300 000 Kč do redesignu. Web vypadal nádherně — velké fotografie, plynulé animace, moderní design.

Problém? Hlavní stránka se načítala 5,8 sekundy. Během dvou týdnů jsme implementovali 7 konkrétních optimalizací. LCP kleslo na 1,9 sekundy. Konverze vzrostly o 31 %.

Proč je Largest Contentful Paint (LCP) králem Core Web Vitals

Připomenutí - co přesně LCP měří

Diagram - Proč je LCP králem Core Web Vitals Largest Contentful Paint (LCP) měří čas, kdy se na obrazovce zobrazí největší viditelný prvek. U většiny webů je to hero obrázek, hlavní banner nebo velký blok textu.

Představte si, že otevíráte web. Vidíte bílou plochu, pak navigaci, pak se postupně objevuje obsah. Moment, kdy uvidíte ten hlavní, největší prvek — to je LCP.

Google stanovil hranice:

Hodnota	Hodnocení
Do 2,5 s	Dobré (zelená)
2,5-4 s	Potřebuje zlepšení (oranžová)
Nad 4 s	Špatné (červená)

Proč Google upřednostňuje LCP před ostatními metrikami

Ze tří Core Web Vitals má LCP největší vliv na vnímání rychlosti uživatelem. Studie ukazují, že většina mobilních uživatelů opustí stránku, pokud se načítá déle než několik sekund. FID a INP (Interaction to Next Paint) měří reakci na kliknutí — ale uživatel musí nejdřív něco vidět, aby mohl kliknout. CLS optimalizace (Cumulative Layout Shift) měří vizuální stabilitu — ale to je relevantní až po načtení obsahu.

LCP je první dojem. A první dojem rozhoduje.

Za roky v SEO jsem viděla weby, kde zlepšení LCP o 1-2 sekundy přineslo měřitelný nárůst konverzí. Ne proto, že by Google lépe hodnotil rychlé weby (i když ano). Ale proto, že uživatelé na rychlých webech nakupují více.

Technika #1: Preload LCP Elementu (Nejrychlejší výhra)

Jak identifikovat LCP element na vašem webu

Diagram - Technika #1: Preload LCP Elementu (Nejrychlejší výhra) Prvním krokem je zjistit, který prvek je na vaší stránce LCP. Není to vždy ten největší obrázek — záleží na viditelné oblasti (viewport).

Postup:

Otevřete PageSpeed Insights
Zadejte URL vaší stránky
V sekci Diagnostics najděte "Largest Contentful Paint element"

Uvidíte přesně, který prvek Google považuje za LCP. Obvykle to je:

Hero obrázek (banner)
Produktová fotografie
Hlavní nadpis H1 (pokud nemáte velké obrázky)
Náhled videa

Implementace `<link rel="preload">` krok za krokem

Preload říká prohlížeči: "Tento soubor budeš potřebovat. Stáhni ho co nejdříve, ještě než na něj narazíš v HTML."

Standardní načítání funguje tak, že prohlížeč čte HTML shora dolů. Narazí na obrázek, teprve pak ho začne stahovat. S preloadem začne stahování okamžitě.

<head>
  <link rel="preload" as="image" href="/images/hero-banner.webp" type="image/webp">
</head>

Důležité atributy:

as="image" — typ zdroje (image, script, style, font)
type="image/webp" — MIME typ (pomáhá prohlížeči rozhodnout)
href — cesta k souboru

Kód a příklad pro WordPress/Shoptet

WordPress (functions.php):

function preload_hero_image() {
    if (is_front_page()) {
        echo '<link rel="preload" as="image" href="' . get_template_directory_uri() . '/images/hero.webp" type="image/webp">';
    }
}
add_action('wp_head', 'preload_hero_image', 1);

Shoptet (úprava šablony): V Shoptetu upravte šablonu header a přidejte před </head>:

{if $homepage}
<link rel="preload" as="image" href="{$shoptet_url}/user/documents/upload/hero-banner.webp" type="image/webp">
{/if}

Očekávaný efekt: Zrychlení LCP o 200-800 ms v závislosti na velikosti obrázku a rychlosti připojení.

Technika #2: Optimalizace Hero Obrázku

AVIF vs WebP vs JPEG - co vybrat

Formát obrázku má obrovský vliv na velikost souboru a tím na rychlost načítání.

Formát	Komprese	Podpora prohlížečů	Kdy použít
JPEG	Základní	100 %	Fallback, starší weby
WebP	O 30 % menší než JPEG	97 %	Standardní volba 2026
AVIF	O 50 % menší než JPEG	93 %	Moderní weby, kde záleží na každém KB

Doporučení: Používejte AVIF s WebP fallbackem. Pro detailní návod viz článek o optimalizaci obrázků.

<picture>
  <source srcset="/images/hero.avif" type="image/avif">
  <source srcset="/images/hero.webp" type="image/webp">
  <img src="/images/hero.jpg" alt="Popis hero obrázku" width="1200" height="600">
</picture>

Responsive images s srcset pro různá zařízení

Proč posílat 2000px široký obrázek na mobil s 400px obrazovkou? To je plýtvání daty a zpomalení.

Srcset umožňuje servírovat různé verze obrázku podle zařízení:

<img
  src="hero-800.webp"
  srcset="hero-400.webp 400w,
          hero-800.webp 800w,
          hero-1200.webp 1200w,
          hero-1600.webp 1600w"
  sizes="(max-width: 600px) 100vw,
         (max-width: 1200px) 80vw,
         1200px"
  alt="Hero banner e-shopu"
  width="1200"
  height="600"
>

Jak připravit obrázky:

Vytvořte 4 verze: 400px, 800px, 1200px, 1600px šířky
Každou verzi uložte jako WebP (nástroj: Squoosh.app)
Kvalitu komprese nastavte na 80-85 %

Fetchpriority="high" - kdy a jak použít

HTML atribut fetchpriority říká prohlížeči, jak důležitý je daný zdroj. Pro LCP element chcete nejvyšší prioritu.

<img
  src="hero.webp"
  fetchpriority="high"
  loading="eager"
  alt="Hlavní banner"
  width="1200"
  height="600"
>

Kdy použít fetchpriority="high":

Hero obrázek (LCP element)
Logo v hlavičce
Hlavní produktová fotografie

Kdy NEPOUŽÍVAT:

Obrázky pod ohybem (below the fold)
Thumbnaily v galerii
Dekorativní prvky

Pozor: Nikdy nekombinujte fetchpriority="high" s loading="lazy" (odložené načítání). To je protimluv — říkáte "načti rychle" a zároveň "načti později".

Technika #3: Zrychlení Serveru (TTFB)

Měření TTFB - jaké hodnoty jsou problematické

Infografika - Technika #3: Zrychlení Serveru (TTFB) TTFB (Time to First Byte) měří, jak dlouho trvá, než server pošle první byte dat. Je to základ — pokud server odpovídá pomalu, všechno ostatní se zpozdí.

Jak změřit TTFB:

V PageSpeed Insights hledejte "Server Response Time"
V Chrome DevTools (F12 → Network → vyberte dokument → Timing → Waiting for server response)

TTFB	Hodnocení
Do 200 ms	Výborné
200-600 ms	Akceptovatelné
Nad 600 ms	Problém

Pokud máte TTFB nad 800 ms, žádná optimalizace obrázků vám nepomůže dostat LCP pod 2,5 sekundy.

Caching strategie: Browser vs Server vs CDN

Cachování ukládá obsah "na později", aby se nemusel generovat nebo stahovat znovu.

1. Browser cache (cache prohlížeče): Prohlížeč si pamatuje stažené soubory. Nastavte správné hlavičky:

# .htaccess pro Apache
<IfModule mod_expires.c>
  ExpiresActive On
  ExpiresByType image/webp "access plus 1 year"
  ExpiresByType image/avif "access plus 1 year"
  ExpiresByType text/css "access plus 1 month"
  ExpiresByType application/javascript "access plus 1 month"
</IfModule>

2. Server cache (page cache): Server si pamatuje vygenerované HTML stránky. Pro WordPress použijte plugin WP Super Cache nebo W3 Total Cache.

3. CDN cache: CDN (Content Delivery Network) ukládá obsah na serverech po celém světě. Uživatel stahuje z nejbližšího serveru.

České hosting řešení s dobrým TTFB

Po letech testování mohu doporučit:

Hosting	TTFB	Cena od	Vhodný pro
Wedos VPS	80-150 ms	150 Kč/měs	Střední weby, e-shopy
Savana	100-200 ms	99 Kč/měs	Malé weby, blogy
Rosti.cz	60-120 ms	200 Kč/měs	Vývojáři, custom řešení
Cloudflare (CDN)	20-80 ms	Zdarma	Všechny weby jako doplněk

Tip: Cloudflare jako CDN vrstvu můžete použít s jakýmkoliv hostingem. Bezplatná verze stačí pro většinu webů.

Technika #4: Eliminace Render-Blocking Resources

Kritické CSS inline - praktická implementace

Render-blocking resources jsou soubory (CSS, JS), které musí prohlížeč stáhnout a zpracovat, než může zobrazit stránku.

Řešení? Kritické CSS (styly potřebné pro obsah nad ohybem) vložte přímo do HTML:

<head>
  <style>
    /* Kritické CSS - pouze styly pro above-the-fold */
    body { font-family: system-ui, sans-serif; margin: 0; }
    .header { background: #1a1a2e; color: white; padding: 1rem; }
    .hero { max-width: 1200px; margin: 0 auto; }
    .hero img { width: 100%; height: auto; }
  </style>
  <link rel="preload" href="/css/main.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
</head>

Nástroje pro extrakci kritického CSS:

Critical (Node.js)
Plugin "Autoptimize" pro WordPress

Defer vs Async pro JavaScript

JavaScript běžně blokuje vykreslování. Řešení: atributy defer a async.

<script src="analytics.js"></script>

<script src="analytics.js" async></script>

<script src="main.js" defer></script>

Atribut	Stahování	Spuštění	Kdy použít
Žádný	Blokuje	Okamžitě	Kritické skripty v `<head>`
async	Paralelně	Po stažení	Analytics, chat widget
defer	Paralelně	Po DOM	Hlavní aplikační logika

Pravidlo: Pro LCP optimalizaci dávejte defer na všechny skripty, které nejsou kritické pro první vykreslení.

Jak najít blokující zdroje v DevTools

Otevřete Chrome DevTools (F12)
Přejděte na záložku Performance
Klikněte na tlačítko nahrávání a refreshněte stránku
Hledejte dlouhé bloky u "Parse HTML" a "Evaluate Script"

Nebo v PageSpeed Insights hledejte doporučení "Eliminate render-blocking resources" — ukáže přesně které soubory blokují.

Technika #5: Resource Hints (preconnect, dns-prefetch)

Kdy použít preconnect pro externí zdroje

Preconnect naváže spojení se serverem ještě před tím, než ho potřebujete. Ušetříte čas na DNS lookup, TCP handshake a TLS negotiation.

<head>
  <link rel="preconnect" href="https://fonts.googleapis.com">
  <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>

  <link rel="preconnect" href="https://cdn.shoptet.cz">
</head>

Kdy použít:

Google Fonts
CDN, odkud načítáte obrázky nebo skripty
API třetích stran (platební brány, chat)

Limit: Nepoužívejte více než 4-6 preconnect. Každé spojení spotřebovává zdroje.

DNS-prefetch pro fonty a analytiku

DNS-prefetch je lehčí varianta — pouze vyřeší DNS jméno na IP adresu. Méně náročné než preconnect.

<head>
  <link rel="dns-prefetch" href="https://www.google-analytics.com">
  <link rel="dns-prefetch" href="https://www.googletagmanager.com">
  <link rel="dns-prefetch" href="https://connect.facebook.net">
</head>

Pravidlo: Pro kritické zdroje (fonty, CDN s obrázky) použijte preconnect. Pro analytiku a tracking použijte dns-prefetch.

Kombinace hints pro maximální efekt

Kompletní příklad pro e-shop:

<head>
  <meta charset="UTF-8">

  <link rel="dns-prefetch" href="https://www.google-analytics.com">
  <link rel="dns-prefetch" href="https://www.googletagmanager.com">

  <link rel="preconnect" href="https://fonts.googleapis.com">
  <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
  <link rel="preconnect" href="https://cdn.example.com">

  <link rel="preload" as="image" href="/images/hero.webp" type="image/webp">

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

  <title>...</title>
</head>

Technika #6: Fonty a Text Rendering

font-display: swap vs optional

Webové fonty mohou způsobit FOIT (Flash of Invisible Text) — text je neviditelný, dokud se font nenačte. Pro LCP je to katastrofa, pokud je LCP element textový.

Řešení: CSS vlastnost font-display.

@font-face {
  font-family: 'CustomFont';
  src: url('/fonts/custom.woff2') format('woff2');
  font-display: swap;
}

Hodnota	Chování	Kdy použít
swap	Okamžitě zobrazí systémový font, po načtení přepne	Většina případů
optional	Zobrazí systémový font, přepne jen při rychlém načtení	Když je vizuální konzistence méně důležitá
fallback	100ms neviditelný, pak systémový, přepne do 3s	Kompromis

Doporučení: Pro LCP optimalizaci používejte font-display: swap. Text se zobrazí okamžitě se systémovým fontem.

Preload fontu - správný způsob

<head>
  <link rel="preload" as="font" href="/fonts/main.woff2" type="font/woff2" crossorigin>
</head>

Důležité: Atribut crossorigin je povinný pro fonty, i když jsou na stejné doméně. Bez něj prohlížeč font nestáhne.

Kolik fontů preloadovat? Maximálně 1-2 nejdůležitější (hlavní text, nadpisy). Každý preload zabírá bandwidth.

System fonts jako fallback

Nejrychlejší font je ten, který není třeba stahovat. Systémové fonty jsou k dispozici okamžitě.

body {
  font-family:
    -apple-system,           /* macOS, iOS */
    BlinkMacSystemFont,      /* macOS Chrome */
    'Segoe UI',              /* Windows */
    Roboto,                  /* Android */
    'Helvetica Neue',        /* starší macOS */
    Arial,                   /* fallback */
    sans-serif;              /* ultimate fallback */
}

Pro e-shopy: Zvažte, zda vlastní font stojí za 200-400 ms zpoždění. Systémové fonty jsou v roce 2026 vizuálně přijatelné.

Technika #7: Server-Side Rendering a Edge

SSR vs CSR - dopad na LCP

CSR (Client-Side Rendering): Prohlížeč stáhne prázdné HTML, pak JavaScript, který vygeneruje obsah. LCP závisí na rychlosti JavaScriptu.

SSR (Server-Side Rendering): Server vygeneruje kompletní HTML. Prohlížeč dostane obsah ihned.

Metoda	LCP	Kdy použít
CSR	Pomalé (3-6s typicky)	Aplikace typu dashboard, admin
SSR	Rychlé (1-2s)	E-shopy, blogy, landing pages
Static Generation	Nejrychlejší (<1s)	Stránky, které se nemění často

Pokud máte React/Vue/Angular aplikaci s pomalým LCP, SSR je nejefektivnější řešení.

Edge caching pro dynamický obsah

Edge computing znamená spouštění kódu na serverech blízko uživatelům (podobně jako CDN).

Místo:

Uživatel v Praze → Server v Německu → Odpověď

Máte:

Uživatel v Praze → Edge server v Praze → Odpověď

Pro dynamický obsah (personalizace, ceny v reálném čase) je edge caching kompromis mezi rychlostí a aktuálností.

Cloudflare Workers pro české weby

Cloudflare Workers umožňují spouštět JavaScript na edge serverech. Praktické použití pro LCP:

// Worker pro optimalizaci obrázků na edge
addEventListener('fetch', event => {
  event.respondWith(handleRequest(event.request))
})

async function handleRequest(request) {
  const url = new URL(request.url)

  // Pokud je to obrázek, optimalizuj
  if (url.pathname.match(/\.(jpg|jpeg|png)$/)) {
    return fetch(request, {
      cf: {
        image: {
          format: 'webp',
          quality: 85,
          fit: 'contain'
        }
      }
    })
  }

  return fetch(request)
}

Výhody pro české weby:

Cloudflare má edge server v Praze
Bezplatný plán stačí pro většinu použití
Automatická konverze obrázků do WebP

Případová studie

📈 E-shop s nábytkem: LCP z 5,8s na 1,9s za 2 týdny

Klientka měla krásně redesignovaný web za 300 000 Kč, ale homepage se načítala 5,8 sekundy. Konverze klesaly, zákazníci odcházeli dřív, než viděli první produkt.

Metrika	Před	Po 2 měsících
Domain Authority	28	35
Organická návštěvnost	4 200/měs	6 100/měs

Co rozhodlo: Kromě technických optimalizací jsme nasadili strategický link building s PR články na DA50+ webech o bydlení a interiérech. Kvalitní zpětné odkazy z tematicky relevantních médií posílily autoritu domény a pomohly rychlejšímu crawlování.

→ Chcete podobné výsledky?

Výchozí stav a analýza

Klient: E-shop s nábytkem, 2 500 produktů, WordPress + WooCommerce.

Počáteční metriky:

LCP (mobil): 5,8 s
TTFB: 1,2 s
Velikost homepage: 8,4 MB
Hero obrázek: 2,1 MB (JPEG, 3200×1800 px)

Hlavní problémy identifikované v auditu:

Obrovský hero obrázek bez komprese
14 externích skriptů blokujících vykreslování
Hosting bez page cache
Fonty bez preload a font-display
Chybějící resource hints

Implementace 7 technik

Týden 1: Obrázky a preload

Hero obrázek: 2,1 MB → 180 KB (AVIF + srcset)
Implementace preload pro LCP element
Přidání fetchpriority="high" a loading="eager"

Týden 2: Server a cache

Migrace na Wedos VPS (TTFB: 1,2 s → 180 ms)
Nasazení WP Rocket pro page cache
Cloudflare CDN aktivace

Změny v kódu (header.php):

<head>
  <link rel="preconnect" href="https://fonts.googleapis.com">
  <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
  <link rel="dns-prefetch" href="https://www.google-analytics.com">

  <link rel="preload" as="image" href="<?php echo get_template_directory_uri(); ?>/images/hero.avif" type="image/avif">
  <link rel="preload" as="font" href="<?php echo get_template_directory_uri(); ?>/fonts/main.woff2" type="font/woff2" crossorigin>

  <style>
    /* Kritické CSS inline */
    .hero { position: relative; }
    .hero img { width: 100%; height: auto; display: block; }
  </style>
</head>

Týden 2: JavaScript a fonty

14 skriptů → 6 skriptů (odstranění nepoužívaných pluginů)
Všechny skripty: defer atribut
Font-display: swap pro všechny fonty

Výsledky a ROI

Metrika	Před	Po	Zlepšení
LCP (mobil)	5,8 s	1,9 s	-67 %
TTFB	1,2 s	180 ms	-85 %
Velikost stránky	8,4 MB	1,2 MB	-86 %
PageSpeed skóre	23	89	+287 %

Obchodní výsledky (po 3 měsících):

Konverzní poměr: 1,1 % → 1,8 % (+63 %)
Bounce rate: 58 % → 41 % (-29 %)
Průměrná doba na stránce: +45 %
Organická návštěvnost: +18 %

ROI: Investice do optimalizace (audit + implementace) se vrátila během 6 týdnů.

Checklist: LCP Optimalizace za Víkend

Rychlé výhry (1 hodina)

Identifikovat LCP element v PageSpeed Insights
Zkomprimovat hero obrázek (Squoosh.app, cíl: pod 200 KB)
Převést na WebP formát
Přidat fetchpriority="high" k LCP obrázku
Přidat loading="eager" k LCP obrázku (ne lazy!)
Ověřit, že obrázky pod ohybem mají odložené načítání (loading="lazy")

Střední náročnost (1 den)

Implementovat preload pro LCP element
Přidat preconnect pro Google Fonts a CDN
Přidat dns-prefetch pro analytiku
Nastavit font-display: swap v CSS
Preloadovat hlavní font (1-2 max)
Nastavit srcset pro responsive images
Aktivovat browser cache (hlavičky expiration)
Nainstalovat caching plugin (WordPress: WP Rocket)

Pro vývojáře (1 týden)

Extrahovat kritické CSS a vložit inline
Přidat defer na všechny nekritické skripty
Odstranit nepoužívané CSS/JS (code splitting)
Implementovat CDN (Cloudflare)
Zvážit SSR pro JavaScript aplikace
Optimalizovat TTFB (lepší hosting, page cache)
Nastavit Cloudflare Workers pro automatickou optimalizaci obrázků

Často kladené otázky (FAQ)

Jaké LCP je považováno za dobré?

Google definuje dobré LCP jako hodnotu pod 2,5 sekundy. Hodnoty 2,5-4 sekundy jsou označeny jako "potřebuje zlepšení" (oranžová). Nad 4 sekundy je "špatné" (červená). Pro e-shopy doporučuji cílit na hodnotu pod 2 sekundy — každá desetina sekundy se projeví na konverzích.

Můžu optimalizovat LCP bez programátora?

Základní optimalizace zvládnete sami: komprese obrázků, konverze do WebP, instalace caching pluginu. Na WordPress existují pluginy (WP Rocket, Autoptimize), které zvládnou preload i kritické CSS automaticky. Složitější zásahy (SSR, custom kód, edge computing) už vyžadují vývojáře.

Jak dlouho trvá, než se zlepšení projeví v Search Console?

Google používá 28denní klouzavý průměr reálných dat od uživatelů (Field Data). Po implementaci optimalizací počítejte 4-6 týdnů, než se změna plně projeví v Search Console. Laboratorní data v PageSpeed Insights uvidíte okamžitě.

Proč je moje LCP na mobilu horší než na desktopu?

Mobilní test simuluje pomalejší připojení (4G místo optiky) a slabší hardware (průměrný Android, ne nejnovější iPhone). Navíc mobily mají menší cache a častěji se potýkají s přerušeným připojením. Pro Google je důležitější mobilní verze — optimalizujte primárně pro mobil.

Co když je můj LCP element video, ne obrázek?

Pokud je LCP element video, optimalizujte náhledový obrázek (poster). Preloadujte poster, ne celé video. Video by mělo mít atribut preload="none" nebo preload="metadata", aby se nenačítalo automaticky. Samotné video spusťte až na interakci uživatele.

<video poster="/images/video-poster.webp" preload="none">
  <source src="/video/intro.mp4" type="video/mp4">
</video>

Související články

LCP: Proč se váš web načítá pomalu a jak to opravit — základy metriky LCP
Core Web Vitals: LCP, INP a CLS jednoduše — kompletní průvodce všemi metrikami
PageSpeed Insights: Jak číst metriky a zrychlit web — návod na měření rychlosti
Optimalizace obrázků: WebP, AVIF a 4 pilíře pro rychlý web — detailní návod na práci s obrázky
Technický SEO audit: 8 oblastí, které brzdí váš web — kompletní checklist

Máte web s pomalým LCP?

Za roky v SEO jsem optimalizovala desítky webů. Vím, kde hledat problémy a jak je rychle vyřešit. Nabízím technický SEO audit, kde zanalyzuji rychlost vašeho webu a připravím konkrétní plán optimalizace.

Objednejte si technický audit