Fotka 4000 px nahraná „jak je“ často vytlačí LCP na mobilu mimo pásmo „dobré“ — web.dev drží práh dobrého LCP na ≤ 2,5 s. Z ostrosti 4000 px ještě neplyne rychlý první paint. Plyne z ní jen, že mobil stahuje megabajty do úzkého viewportu.
Klient chválí ostrost, PageSpeed hlásí hero
Hero z foťáku jde rovnou do CMS. LCP element = hero, bounce stoupá. „4,8 s“ z topic banky je story příklad PageSpeed, ne CrUX průměr — neberte ho jako univerzální konstantu.
LCP ≤ 2,5 s (75. percentil)
web.dev (Core Web Vitals): dobré LCP je ≤ 2,5 s (75. percentil, mobil i desktop zvlášť) — web.dev LCP. 2,5 s je práh „good“, ne garance po jednom resize. Lazy-load na LCP hero je anti-pattern; LCP obrázek chce fetchpriority="high" a správnou velikost.
Šířka × DPR, WebP/AVIF, srcset/sizes
Kandidáti cca 480 / 768 / 1200 px + moderní formát, ne jeden full-res upload. srcset/sizes podle layoutu. Komprese JPEG nestačí, pokud servírujete 4000 px do 390px viewportu — viz i responsive images.
Priorita LCP ≠ lazy všude
Hero, který je LCP element, nepatří do blanket lazy-loadu. Až pod foldem lazy dává smysl. Nejdřív správná šířka a formát, pak priority — jinak mobil stahuje 4000 px a teprve potom kreslí „dobré“ LCP mimo pásmo.
kontrolní seznam omylů kolem 4000px hero
- Nahrát full-res „jak je“ do CMS.
- Brát 4,8 s jako CrUX průměr.
- Zapnout lazy-load na LCP hero.
- Spokojit se s „zkomprimuj JPEG“ bez srcset.
- Měřit jen desktop a ignorovat mobilní 75. percentil.
- Čekat, že 2,5 s práh spadne sám po jednom resize bez formátu a priority.
LCP je čas do největšího obsahu. Ostrost bez velikosti viewportu je jen těžký soubor.
