Nejpomalejší věc na webu bývá kupodivu ta, na které si majitel dal nejvíc záležet: velká fotka přes celou úvodní obrazovku. Právě ji totiž nejčastěji měří LCP (Largest Contentful Paint) — čas, za který se návštěvníkovi vykreslí největší prvek viditelné části stránky. Google počítá hodnoty do 2,5 vteřiny jako dobré, nad 4 vteřiny jako špatné. Špatné LCP přitom málokdy znamená přestavbu webu: většinou jde o pět konkrétních závad a na část z nich nepotřebujete ani vývojáře.
Co přesně LCP měří
LCP stopuje jediný okamžik: kdy se ve viditelné části stránky dokreslí její největší prvek. Obvykle je to úvodní obrázek nebo velký nadpis, u videa náhledový snímek. Všechno ostatní se klidně může ještě načítat. Rozhoduje moment, kdy návštěvník vidí to hlavní a přestane mít pocit, že čeká.
Mezi dobrou hodnotou (do 2,5 s) a špatnou (nad 4 s) leží ještě pásmo „potřebuje zlepšení". Hodnotí se 75. percentil, takže stránka projde, když se do limitu vejdou aspoň tři čtvrtiny skutečných načtení; jedno pomalé otevření v tramvaji vás nepotopí.
LCP je jedna ze tří metrik, kterými Google měří zážitek z webu; zbylé dvě jsou INP (reakce na kliknutí) a CLS (poskakování obsahu). Přehled všech tří najdete v článku o Core Web Vitals. Proč se web načítá pomalu a jak metrika vznikla, rozebírá starší článek o LCP; tenhle text je jeho praktické pokračování — co opravit a v jakém pořadí.
Změřte, než začnete opravovat
Do PageSpeed Insights zadáte adresu a dostanete dvě různé pravdy. Nahoře polní data: skutečná měření od lidí, kteří na webu za posledních 28 dní opravdu byli (anonymně je sbírá Chrome). Pod nimi laboratorní test: jedna simulace načtení na průměrném mobilu s pomalejší sítí. Rozhodují polní data, s těmi pracuje Google. Laboratorní test berte jako lupu: ukáže, kde přesně to vázne. Jak celý report číst, popisuju v návodu na PageSpeed Insights.
Menší weby polní data nemívají — Google jich nemá dost naměřeno. PageSpeed pak ukáže souhrn za celou doménu, nebo nic, a vám zbývá laboratorní test. Berte ho s rezervou: každé spuštění dopadne trochu jinak.
Jednu položku si z výsledků odneste vždycky: „Largest Contentful Paint element" v diagnostice. Ukáže konkrétní prvek, který se na vaší stránce měří. Dokud ho neznáte, opravujete poslepu — klidně byste týden ladili obrázek, zatímco vaše LCP je nadpis čekající na písmo.
Kolik zákazníků vám tenhle měsíc uteče ke konkurenci jen proto, že vás Google nenabídne? Pošlete mi adresu webu — do 48 hodin víte, co opravit, aby vás lidé našli. Audit dělám ručně a zdarma.
Pět míst, kde se čas ztrácí
Seřazeno podle toho, co u webů potkávám nejčastěji. U každé páky píšu i to, kdo ji zvládne: vy v administraci, nebo vývojář.
1. Obrázek nahoře
Nejčastější viník a nejvděčnější oprava. Tři kontroly:
- Rozměry. Fotka se na stránce zobrazuje široká třeba 1 200 pixelů, ale nahraná je v původní velikosti z fotobanky, několikrát větší. Návštěvník pak stahuje megabajty, ze kterých neuvidí nic. Exportujte obrázek ve velikosti, v jaké se skutečně ukazuje.
- Formát a komprese. WebP nebo AVIF umí stejně vypadající fotku o desítky procent menší než starý JPEG. Podrobný postup máte v článku o optimalizaci obrázků.
- Priorita. Úvodní obrázek nikdy nesmí mít lazy loading (odložené načítání). Tím prohlížeči říkáte „tenhle obrázek nespěchá" — u toho jediného, který spěchá nejvíc. Google to v dokumentaci uvádí výslovně. Opačným směrem umí vývojář prioritu zvednout (atribut fetchpriority, případně preload) a je to úprava na pár řádků kódu.
První dvě věci zvládnete sami v administraci nebo grafickém editoru, třetí je pro vývojáře.
2. Server: než dorazí první bajt
TTFB (time to first byte) je čas, než server vůbec začne odpovídat. Všechno ostatní se k němu jen přičítá: když server přemýšlí vteřinu a půl, nezachrání vás sebelehčí obrázek. Google doporučuje držet TTFB do 0,8 vteřiny.
Co pomáhá: zapnutá cache (u WordPressu ji řeší plugin, e-shopová řešení ji mívají v nastavení hostingu), vyšší tarif nebo přesun k rychlejšímu hostingu, u návštěvníků z více zemí CDN. Cache plugin zapnete sami; stěhování hostingu už chce někoho, kdo web zná.
3. Skripty a styly, které blokují vykreslení
Prohlížeč nevykreslí nic, dokud nezpracuje styly a skripty v hlavičce stránky. Každý měřicí kód, chatovací okno, popup nástroj a pozůstatek dávno opuštěného pluginu tam přidává čekání: stránka už je stažená, ale obrazovka pořád bílá.
Sami zvládnete inventuru — projít seznam pluginů a nástrojů třetích stran a škrtnout, co se nepoužívá. Nejrychlejší skript je ten, který na webu není. Zbytek je zadání pro vývojáře a zní jednoduše: skripty, které nejsou potřeba k prvnímu vykreslení, odložit až za něj.
4. Písmo
Týká se hlavně webů, kde je největším prvkem nadpis. Prohlížeč v základním nastavení čeká s textem, dokud se nestáhne webové písmo, takže návštěvník kouká na prázdné místo, kde dávno mohl číst. Oprava je jedna vlastnost v CSS: font-display: swap. Text se ukáže hned v systémovém písmu a po stažení se tiše vymění. K tomu jedna otázka při každé revizi šablony: kolik řezů písma web doopravdy potřebuje? Každý další se stahuje.
5. Přesměrování
Přehlížený žrout času. Návštěvník klikne na odkaz a stránka se ještě ani nezačala načítat, protože prohlížeč skáče řetězem přesměrování: z http na https, z adresy bez www na www, ze staré adresy na novou. Každý skok znamená další cestu na server a zpátky, na mobilní síti klidně stovky milisekund. Nejčastěji to schytají příchody z reklam a zkrácených odkazů. Kontrola je snadná: vložte do prohlížeče adresu přesně v podobě, v jaké ji máte v reklamách a na sociálních sítích, a sledujte, přes kolik adres doputujete. Srovnat pravidla tak, aby se skákalo nanejvýš jednou, je práce pro správce hostingu nebo vývojáře.
Řekněte vývojáři, co chcete — konkrétně
Rozdíl mezi zakázkou, která web zrychlí, a fakturou za „optimalizaci" bývá v zadání. „Zrychli web" se splnit nedá; tohle ano:
- „Úvodní obrázek nesmí mít lazy loading a má dostat vysokou prioritu načítání."
- „Skripty, které nejsou potřeba k prvnímu vykreslení, odlož za něj."
- „Webová písma nastav na font-display: swap a zkontroluj počet řezů."
- „Projdi řetěz přesměrování z reklamních adres, ať je nanejvýš jeden skok."
S takovým seznamem se práce dá odhadnout, ocenit i zkontrolovat.
Nejste si jistí, jestli to děláte správně? Vstupní SEO audit u mě máte zdarma.
Kdy LCP neřešit
Když polní data svítí zeleně, nechte web být a věnujte čas jinam. Honit v laboratorním testu skóre 100 je koníček, ne investice: rozdíl mezi 1,8 a 1,2 vteřiny návštěvník nepozná a Google za něj nic navíc nedá. Rychlost je při hodnocení stránek slabší signál, než jak tvrdí články, které vám chtějí zrychlování prodat — o pozicích rozhoduje především obsah. Smysl má LCP řešit ve chvíli, kdy polní data ukazují oranžovou nebo červenou, protože tam už na pomalé načítání narážejí skuteční lidé. A i zelené LCP je jen třetina obrazu: web umí být rychle načtený, a přesto tuhý při kliknutí nebo uskakující pod prstem.
Časté otázky
Za jak dlouho se oprava projeví?
V laboratorním testu hned — spusťte ho po nasazení znovu a uvidíte rozdíl. Polní data jsou klouzavý souhrn za 28 dní, takže se zlepšení propisuje postupně a plný obraz uvidíte zhruba po měsíci. Stejné metriky hlídá i přehled Core Web Vitals v Search Console, včetně e-mailu, když se něco pokazí.
Proč mám na mobilu horší čísla než na počítači?
Laboratorní mobilní test schválně simuluje slabší telefon a pomalejší síť, aby odhalil rezervy. A polní data z mobilů bývají horší prostě proto, že lidé web otvírají na horším připojení, než je vaše kancelářské. Mobil a počítač se hodnotí zvlášť — a protože na mobilu bývá hůř, v praxi rozhoduje on.
Zvedne mi rychlejší LCP pozice v Googlu?
Samo o sobě většinou ne; rychlost je jeden z řady signálů a slabší než obsah. Skoro vždycky se ale zrychlení pozná na chování návštěvníků: méně jich odejde dřív, než se stránka vůbec ukáže. Proto má LCP cenu řešit i na webu, kterému pozice šlapou.
Jeden test není diagnóza
PageSpeed spustíte desetkrát a dostanete deset trochu jiných čísel. Proto rychlost žádného webu neposuzuju podle jednoho běhu, ale z polních dat — z toho, co za poslední měsíc zažili skuteční návštěvníci. Stejně se dívám na weby, které mi majitelé posílají na audit: rychlost je v něm jedna kapitola vedle obsahu, technického stavu a viditelnosti ve vyhledávání, ať víte, jestli vteřiny řešit teď, nebo až po důležitějších věcech.
Zdroje k faktům v článku:
- LCP: definice, typy prvků (obrázek, text, náhled videa), hranice 2,5 s a 4 s, 75. percentil (ověřeno 16. 7. 2026): web.dev/articles/lcp
- Optimalizace LCP: zákaz lazy loadingu na LCP obrázek, fetchpriority a preload, vliv řetězů přesměrování (ověřeno 16. 7. 2026): web.dev/articles/optimize-lcp
- TTFB: doporučení do 0,8 s (ověřeno 16. 7. 2026): web.dev/articles/ttfb
- PageSpeed Insights: polní data z CrUX za klouzavých 28 dní vs. laboratorní test Lighthouse (ověřeno 16. 7. 2026): developers.google.com/speed/docs/insights/v5/about
