LCP a rychlost načtení

LCP je čas, po kterém návštěvník uvidí hlavní věc na stránce. Když je delší než čtyři sekundy, většina lidí na mobilu už dávno odešla a je jedno, jak dobrý máte text pod tím.

Který prvek je ten největší

Prohlížeč sleduje, který viditelný prvek zabírá v prvním okně největší plochu. Nejčastěji je to hlavní fotka v hlavičce, video plakát, obrázek produktu nebo velký nadpis. Ten prvek určuje vaše LCP, ostatní obsah se do metriky nepočítá.

První krok při každé opravě je zjistit, o který prvek jde. V PageSpeed Insights je vypsaný přímo, v prohlížeči ho najdete v panelu výkonu. Bez tohoto kroku lidé optimalizují patičku a diví se, že se nic nezlepšilo.

Praktický důsledek: pokud je LCP prvkem obrovská fotka na pozadí hlavičky, celá práce se točí kolem ní. Pokud je to nadpis, řešíte fonty a blokující skripty. Jsou to dva úplně jiné postupy a záměna je nejčastější chyba.

Pět příčin, které dělají devadesát procent problému

Obrázek v nesprávném formátu a velikosti. Fotka 4000 pixelů široká a 3 megabajty velká, zobrazená na mobilu v šířce 380 pixelů. Sama o sobě přidá dvě až čtyři sekundy na mobilních datech. Tohle je nejčastější jediná příčina špatného LCP v Česku.

Fonty načítané z externího zdroje. Prohlížeč čeká na stažení fontu, než vykreslí nadpis, a když je nadpis LCP prvkem, čeká se na něj. Připočtěte DNS dotaz na cizí doménu a máte půl sekundy pryč, než se vůbec začne stahovat.

Zbylé tři příčiny jsou pomalá odpověď serveru, blokující skripty v hlavičce a načítání LCP obrázku až po spuštění JavaScriptu. Ta poslední je zákeřná: obrázek v karuselu nebo v komponentě, která se vykreslí až po načtení skriptu, začne stahovat o dvě sekundy později, než by mohl.

• Předimenzovaný obrázek bez moderního formátu
• Fonty z externí domény bez předběžného načtení
• Pomalá odpověď serveru nad 600 ms
• Blokující CSS a JavaScript v hlavičce
• LCP obrázek načítaný až skriptem
• Chybějící přednostní načtení hlavního obrázku
• Karusel na místě hlavního vizuálu

Obrázky: co s nimi konkrétně udělat

Převeďte hlavní vizuály do WebP nebo AVIF. U fotek to znamená úsporu šedesát až osmdesát procent datové velikosti při stejném vzhledu. Fotka, která měla 2,4 MB, má po převodu kolem 300 kB a to je na mobilních datech rozdíl asi dvou sekund.

Servírujte různé velikosti pro různá zařízení pomocí atributu srcset. Mobil dostane variantu 800 pixelů, desktop 1920. Nemá smysl posílat na telefon obrázek pro velký monitor. K tomu vždy uvádějte šířku a výšku, ať se nepřepočítává rozvržení.

Hlavní obrázek nikdy neodkládejte líným načítáním. Lazy loading patří na fotky pod ohybem stránky, ne na LCP prvek. Naopak mu přidejte přednostní načtení, aby prohlížeč věděl, že je důležitý. Tahle jedna změna umí ubrat půl až celou sekundu.

Fonty a skripty, které stojí v cestě

Fonty hostujte u sebe, ne z cizí domény. Ušetříte navázání spojení a získáte kontrolu nad tím, jak se chovají při načítání. Nastavte je tak, aby se text zobrazil hned náhradním písmem a po dotažení se prohodil. Nikdo raději nečeká na dokonalé písmo se zavřenýma očima.

Načítejte jen řezy, které skutečně používáte. Typický web má v kódu šest řezů a používá dva. Každý nepoužitý řez je zbytečných třicet až osmdesát kilobajtů a jedno spojení navíc. Zúžení znakové sady na latinku s diakritikou ubere dalších čtyřicet procent.

Skripty pro analytiku, chat, cookies lištu a widget hodnocení patří za obsah, ne před něj. Načítejte je odloženě. Chatovací widget načtený hned je běžně 200 až 400 kilobajtů JavaScriptu, který stojí ve frontě před vaší hlavní fotkou.

Hosting a kde se ztrácí první sekunda

Odpověď serveru by měla přijít do 600 milisekund, ideálně do 300. Sdílený hosting za 60 korun měsíčně běžně odpovídá za sekundu a půl a to je čas, který nedoženete žádnou optimalizací obrázků. Je to jediná položka, kde se opravdu vyplatí připlatit.

U redakčních systémů řeší většinu problému kvalitní cache, která vrací hotovou stránku místo toho, aby se generovala z databáze při každé návštěvě. U statických webů tenhle problém neexistuje, protože se servírují už hotové soubory. To je jeden z důvodů, proč weby stavím jako statické stránky s dynamickými částmi jen tam, kde jsou nutné.

CDN pomáhá, když máte návštěvníky z různých míst. U webu, který obsluhuje jen český trh, přinese CDN typicky sto až dvě stě milisekund, tedy hezký, ale ne rozhodující bonus. Nejdřív obrázky a server, CDN až potom.

• Odpověď serveru do 600 ms, měřeno na mobilu
• Cache hotových stránek u redakčních systémů
• Statické generování tam, kde to jde
• Komprese odpovědí zapnutá
• CDN až po vyřešení obrázků a serveru

Kolik oprava LCP stojí

Nejlevnější balík jsou obrázky a fonty. Převod, varianty podle zařízení, přednostní načtení hlavního vizuálu a nastavení písem. Na běžném webu to dělá 9 900 a hotové to je za dva až tři dny. U většiny webů tenhle jeden zásah stáhne LCP ze čtyř sekund pod dvě a půl.

Když je problém i v serveru a ve skriptech, přidává se práce na cache, odložení externích knihoven a úklid kódu hlavičky. Kompletní optimalizace vychází od 24 900. Nad tuhle hranici už dává smysl porovnat cenu s novým webem od 19 990, protože nový postavený správně bude rychlý od začátku a nebudete platit za obcházení cizích chyb.

Provoz s hostingem, zálohami a dohledem je 990 měsíčně, péče s průběžnými úpravami 2 990. Kontrolu měřím měsíc po nasazení, protože reálná data v Search Console se počítají z okna 28 dní a dřív se změna neprojeví celá.

Časté otázky

Jak poznám, který prvek je můj LCP?

Nejrychleji v PageSpeed Insights, kde je LCP prvek vypsaný pod výsledky. Alternativně v prohlížeči v panelu výkonu, kde se dá zvýraznit přímo na stránce. Bez tohoto kroku hrozí, že budete optimalizovat něco, co se do metriky vůbec nepočítá, a výsledek se nezmění.

Stačí zmenšit obrázky, nebo musím měnit hosting?

U většiny webů obrázky a fonty stáhnou LCP pod hranici samy. Hosting řešte, až když odpověď serveru přesahuje 600 milisekund. Změřte si ji jako čas do prvního bajtu. Pokud je pod 300 milisekund, hosting není váš problém a měnit ho nic nepřinese.

Pomůže rychlejšímu načtení odstranění karuselu?

Obvykle ano a hned dvakrát. Karusel nese více obrázků, než je potřeba, a často je vykreslený až JavaScriptem, takže se LCP obrázek začne stahovat později. Nahrazení jedním statickým vizuálem s jasným sdělením zkracuje načtení o půl až sekundu a zpravidla zlepšuje i konverzi.