Proč LCP nejčastěji zabíjí právě jeden prvek

Largest Contentful Paint (LCP) měří, kdy se uživateli zobrazí největší viditelný prvek v nadpřehledu. V praxi to bývá obrázek, hero sekce, velký nadpis nebo blok s pozadím. Google doporučuje dostat se pod 2,5 s pro dobrý zážitek, ale na mnoha webech se LCP natahuje na 4–6 sekund i víc, i když server odpovídá relativně rychle.

Nejčastější omyl je hledat viníka v jedné „velké“ věci: hosting, CDN, WordPress, šablona. Jenže ve skutečnosti LCP často zdržuje jedna drobnost v nadpřehledu – například obrázek v nevhodném formátu, CSS, které blokuje render, nebo lazy-loading na prvku, který má být vidět hned. Tohle je důležité: LCP není jen o rychlosti stahování, ale o tom, kdy se konkrétní prvek stane viditelným.

V reportech z PageSpeed Insights nebo Lighthouse často uvidíte, že „LCP element“ je právě ten jediný hero obrázek. Pokud má 300–800 KB, je ve špatném rozměru a ještě navíc není prioritizovaný, máte problém. A pokud se k tomu přidá blokující CSS nebo pomalé načítání fontu, výsledná hodnota LCP se posune o celé sekundy.

Jak zjistit, co přesně LCP zpomaluje

Začněte v Google PageSpeed Insights a Lighthouse. V detailu LCP najdete rozpad na několik částí: TTFB, load delay, load time a render delay. Tohle je zásadní, protože vám ukáže, jestli je problém na serveru, v prioritizaci zdroje, nebo až ve vykreslení na straně prohlížeče.

  • TTFB vysoké znamená pomalou první odpověď serveru nebo backendu.
  • Load delay bývá typicky způsobený tím, že se LCP prvek objevuje pozdě v HTML nebo je zbytečně odkládán.
  • Load time ukazuje na těžký obrázek, video nebo neoptimalizovaný asset.
  • Render delay často souvisí s CSS, JavaScriptem, fonty nebo main-thread blokací.

Pro reálnou diagnostiku doporučuji i Chrome DevTools v záložce Performance. Tam uvidíte, kdy se konkrétní prvek načetl a kdy byl skutečně vykreslen. Na větších webech se vyplatí porovnat také data z Search Console v sekci Core Web Vitals a z GA4, pokud máte nasazené vlastní měření výkonu.

Praktický postup: otevřete stránku v anonymním okně, spusťte Lighthouse, identifikujte LCP element a podívejte se, zda jde o obrázek, text nebo blok s pozadím. Pak si položte jedinou otázku: co přesně mu brání být vidět dřív? Ve většině případů najdete odpověď během pár minut.

Nejčastější drobnost: hero obrázek je těžký, špatně prioritizovaný nebo v nevhodném formátu

Na zhruba 60–80 % marketingových a firemních webů je LCP elementem hlavní obrázek v hero sekci. A právě ten bývá nejčastěji problém. Typická chyba: designér dodá vizuál v rozměru 2400 px, vývojář ho vloží jako běžný obrázek bez optimalizace a CMS ho servíruje v plné kvalitě i mobilu. Výsledek? Na mobilu se stahuje soubor, který je několikanásobně větší, než je potřeba.

Co s tím:

  • používejte AVIF nebo WebP místo JPG/PNG, pokud to dává smysl;
  • nastavte správné rozměry podle breakpointů, ne jeden univerzální export;
  • u LCP obrázku nepoužívejte lazy-loading;
  • přidejte fetchpriority=“high“ nebo preload, pokud je to vhodné;
  • zajistěte, aby byl obrázek v HTML nebo načtený co nejdřív, ne až přes JS.

Jednoduchý příklad: hero obrázek o velikosti 650 KB na mobilu může po optimalizaci klesnout na 90–140 KB. To není kosmetika, ale rozdíl, který často zlepší LCP o 0,5 až 1,5 sekundy. U pomalejších sítí i víc. Pokud navíc přidáte preload a eliminujete zbytečné blokování renderu, efekt se násobí.

Pozor na background-image v CSS. Pokud je hero vizuál nastavený jako background-image v hero sekci, prohlížeč ho často objeví později než běžný <img>. Pro LCP je bezpečnější pracovat s reálným obrázkem v HTML, protože se lépe prioritizuje a snáz diagnostikuje.

CSS, fonty a JavaScript: drobný blokátor, velký dopad

Další nenápadný zabiják LCP je render-blocking CSS. Pokud web načítá velký balík stylů před prvním vykreslením, prohlížeč čeká, než si je stáhne a zpracuje. To se pak projeví jako vysoký render delay. U velkých WordPress šablon nebo page builderů není výjimkou CSS přes 200–500 KB, často navíc s velkým množstvím nevyužitého kódu.

Co funguje v praxi:

  • vytvořit critical CSS pro nadpřehled;
  • odložit neurgentní styly až po prvním vykreslení;
  • omezit množství webfontů a variant řezů;
  • u fontů použít font-display: swap;
  • odložit neesenciální JavaScript pomocí defer nebo async tam, kde to dává smysl.

Fonty jsou podceňované. Když hero nadpis čeká na načtení custom fontu, může se LCP posunout, protože text se buď nevykreslí hned, nebo dojde k posunu layoutu. To je problém nejen pro performance, ale i pro UX. U textového LCP je často lepší použít systémový font a custom font doručit až následně, pokud to nepoškodí brand.

JavaScript bývá problém hlavně tehdy, když hero sekce závisí na skriptu: animace, slider, cookie lišta, A/B testování nebo měřicí nástroje. Každý skript navíc soutěží o main thread. Pokud máte na stránce 10+ externích skriptů, není neobvyklé, že LCP trpí spíš kvůli vykreslení než kvůli přenosu dat.

Jak opravu LCP zkontrolovat a měřit bez domněnek

Po úpravách nestačí „pocit, že je to rychlejší“. Potřebujete ověřit reálný dopad. V ideálním případě testujte ve třech vrstvách: laboratorní měření, field data a obchodní dopad. Laboratorně použijte PageSpeed Insights nebo Lighthouse, field data sledujte v Search Console a ve vlastním RUM měření, obchodní dopad pak v GA4 podle bounce rate, engagement rate a konverzí.

Konkrétní workflow:

  • před změnou si uložte screenshot reportu a hodnotu LCP;
  • změřte velikost LCP assetu před a po optimalizaci;
  • porovnejte TTFB, render delay a load time;
  • na reálných uživatelích sledujte změny na mobilech, kde bývá zlepšení největší;
  • ověřte, že se nezhoršila vizuální stabilita, tedy CLS.

U e-shopů a lead-gen webů má smysl sledovat výsledky po šablonách, ne jen na homepage. Často se totiž ukáže, že homepage má LCP v pořádku, ale kategorie nebo landing page mají hero sekci zbytečně těžkou. A právě tam se ztrácí návštěvnost z organiku i placených kampaní.

Pokud pracujete ve WordPressu, hodně pomůže kombinace nástrojů jako Perfmatters, WP Rocket, Asset CleanUp nebo serverové optimalizace na úrovni hostingu. U headless nebo Next.js webů zase sledujte, zda se LCP neblokuje hydratačním procesem nebo příliš pozdním renderem komponenty. Technologie je jiná, princip stejný: LCP prvek musí být dostupný co nejdřív a bez zbytečných překážek.

Největší posun obvykle nepřinese „další plugin“, ale odstranění jedné chyby v nadpřehledu. Když je LCP prvek lehký, prioritizovaný a nemusí čekat na CSS, fonty ani JavaScript, web působí rychleji okamžitě. A to je přesně ten rozdíl, který Google i uživatelé poznají během prvních sekund.