Co lazy loading ve skutečnosti dělá s vaším Largest Contentful Paint

Lazy loading je rozhodnutí o plánování, ne kouzlo na zrychlení

Lazy loading se často popisuje jako zlepšení výkonu, což je pravda podobně jako tvrzení, že nesbalit si kufr znamená snížit hmotnost. Pomáhá proto, že prohlížeč udělá na začátku méně práce.

Toto rozlišení je důležité pro Largest Contentful Paint, obvykle zkracovaný na LCP. LCP měří, kdy se vykreslí největší smysluplný prvek ve viewportu. Na mnoha stránkách je tímto prvkem hero obrázek. Na jiných je to velký nadpis, poster obrázek, produktová fotografie nebo blok obsahu.

Lazy loading mění okamžik, kdy jsou zdroje vyžádány. Nezpůsobí, že se obrázek rychleji dekóduje, server rychleji odpoví nebo font dříve vykreslí. Pokud lazy loadujete špatnou věc, zejména prvek, který se stane LCP, říkáte prohlížeči, aby počkal, než začne stahovat právě to, co musí zobrazit, aby stránka obstála v Core Web Vitals.

Proto se lazy loading zároveň používá příliš často a příliš málo mu rozumíme.

Co prohlížeč dělá, když u obrázku použijete lazy loading

Nativní lazy loading obrázků se obvykle přidává takto:

<img src='hero.jpg' loading='lazy' alt='...'>

S loading='lazy' smí prohlížeč odložit stažení obrázku, dokud neusoudí, že bude obrázek pravděpodobně potřeba. V praxi prohlížeče používají vzdálenost od viewportu, podmínky sítě, rozměry obrázku a další heuristiky. Přesná pravidla jsou implementační detaily a mohou se měnit.

S loading='eager', nebo ve většině případů bez atributu lazy, prohlížeč zachází s obrázkem jako se součástí běžného procesu načítání. Stále musí prioritizovat mezi CSS, JavaScriptem, fonty, obrázky a dalšími požadavky, ale obrázek je objevitelný okamžitě.

To znamená, že lazy loading ovlivňuje především tři fáze:

• Objevení: kdy si prohlížeč zdroje všimne.
• Začátek požadavku: kdy začne síťové stažení.
• Čas vykreslení: kdy může být zdroj konečně dekódován a vykreslen.

Pro LCP je nebezpečný začátek požadavku. Pokud požadavek na LCP obrázek začne pozdě, všechno po něm se také posune později.

Jednoduché pravidlo: nikdy nepoužívejte lazy loading pro kandidáta na LCP

Pokud je obrázek viditelný v počátečním viewportu a pravděpodobně bude největším obsahovým prvkem, nepoužívejte pro něj lazy loading.

To zahrnuje:

• hero obrázky
• primární produktové fotografie nad přehybem stránky
• velké úvodní obrázky článků
• velké obrázky podobné pozadí implementované jako <img>
• video poster obrázky, pokud je poster hlavním vizuálním prvkem

Prohlížeč nemůže LCP obrázek vykreslit, dokud nebyl vyžádán, přenesen, dekódován a vykreslen. Lazy loading vkládá nejistotu před první krok. I malé zpoždění může stačit k tomu, aby se LCP na pomalejším připojení posunulo z přijatelného na špatné.

Běžný vzorec selhání vypadá takto:

1. Server odešle HTML.
2. Prohlížeč zpracuje obrázek nad přehybem stránky.
3. Obrázek má loading='lazy'.
4. Prohlížeč čeká, protože heuristika lazy loadingu říká, že může.
5. CSS a JavaScript se dál načítají.
6. Požadavek na obrázek začne později, než by měl.
7. LCP je opožděné, i když samotný soubor obrázku je rozumně optimalizovaný.

Je to frustrující, protože při code review může stránka vypadat upraveně. Problém není jen velikost souboru. Je to priorita.

Pokud čtete výstup z laboratorního nástroje a snažíte se zjistit, zda je LCP skutečně problém, náš průvodce čtením Lighthouse reportu bez paniky je záměrně praktický: oddělte field data, laboratorní náznaky a opravy dřív, než začnete měnit kód. (Poznámka: pokud vaše routování rozlišuje velikost písmen, použijte přesnou URL z vašeho CMS.)

Oprava: použijte skutečnou interní URL

Správná URL článku Wux je Jak číst Lighthouse report bez paniky. Pointa zůstává: určete LCP prvek dříve, než změníte chování načítání.

Kdy může lazy loading zlepšit LCP

Lazy loading může LCP zlepšit nepřímo, když udrží nekritické zdroje mimo cestu prohlížeče.

Představte si produktovou stránku s hero produktovým obrázkem nahoře a karuselem dvanácti doporučených obrázků pod přehybem stránky. Pokud se všech třináct obrázků načítá eager, prohlížeč může utrácet šířku pásma a spojovací sloty za obrázky, které uživatel ještě nevidí. Na omezené síti to může soupeřit s hero obrázkem, CSS nebo soubory fontů.

Lazy loading obrázků v karuselu pod přehybem může pomoct LCP obrázku načíst se dříve, protože během počátečního načítání stránky soutěží méně nekritických požadavků.

Toto je legitimní výkonnostní důvod pro lazy loading:

• eager načítejte kandidáta na LCP nad přehybem stránky
• lazy loadujte obrázky pod počátečním viewportem
• vyhněte se těžkým skriptům, které důležité obrázky vkládají pozdě
• ponechte rozměry obrázků v HTML, abyste předešli posunům layoutu

Lazy loading není optimalizace LCP sám o sobě. Je to nástroj pro prioritizaci zdrojů. Pomáhá, když chrání kritickou cestu.

Lepší vzor pro LCP obrázky

U LCP obrázku nad přehybem stránky je cílem zajistit, aby ho prohlížeč objevil brzy, vyžádal si ho brzy a vykreslil ho bez nestability layoutu.

Solidní základ vypadá takto:

<img
  src='/images/product-hero.avif'
  srcset='/images/product-hero-800.avif 800w, /images/product-hero-1400.avif 1400w'
  sizes='(max-width: 768px) 100vw, 720px'
  width='1400'
  height='900'
  loading='eager'
  fetchpriority='high'
  decoding='async'
  alt='Black hiking backpack with roll-top closure'
>

Důležité části nejsou dekorativní:

• loading='eager' brání zpoždění způsobenému lazy loadingem.
• fetchpriority='high' říká prohlížeči, že na tomto obrázku záleží.
• width a height rezervují místo a snižují posun layoutu.
• srcset a sizes brání stahování zbytečně velkých souborů.
• Moderní formát může při pečlivém použití zkrátit čas přenosu.

Pokud stále servírujete jeden velký JPEG pro každou obrazovku, formát obrázku a responzivní velikosti mohou být důležitější než atribut lazy loadingu. Praktický rozhodovací strom najdete v článku kdy AVIF poráží WebP a kdy ne.

Obrázky na pozadí vyžadují zvláštní péči

CSS obrázky na pozadí nejsou objeveny tak brzy jako běžné HTML obrázky. Prohlížeč musí nejdřív stáhnout a zpracovat CSS, než se o nich dozví. Pokud je vaším LCP prvkem CSS obrázek na pozadí, už jste jeho objevení ztížili.

To neznamená, že obrázky na pozadí jsou zakázané. Znamená to, že byste je měli používat záměrně.

Pro dekorativní obrázky jsou CSS pozadí v pořádku. Pro smysluplnou hero grafiku je obvykle lepší prvek <img> nebo <picture>, protože je viditelný pro HTML parser, podporuje alt text a dobře funguje s atributy pro responzivní obrázky.

Pokud musíte pro LCP obrázek použít CSS pozadí, zvažte jeho preload:

<link rel='preload' as='image' href='/images/hero.avif'>

Ani preload není kouzelná hůlka. Preload příliš mnoha obrázků vytváří stejný problém s prioritami, jen v jiném kostýmu. Použijte ho pro jeden obrázek, na kterém opravdu záleží, ne pro každý obrázek v design systému.

JavaScriptový lazy loading často věci zhoršuje

Než byla široce podporována nativní podpora lazy loadingu, mnoho webů používalo JavaScriptové knihovny, které po načtení stránky nebo po spuštění intersection observeru prohodily data-src do src. Některé to dělají stále.

Pro dlouhé článkové stránky nebo galerie s mnoha obrázky to může dávat smysl. Pro obsah nad přehybem stránky je to špatná volba.

Preload scanner prohlížeče je rychlý, ale nemůže vyžádat obrázek, jehož URL je skrytá ve vlastním atributu, dokud neběží JavaScript. Pokud váš hero obrázek začíná jako data-src='hero.jpg', odložili jste jeho objevení až za stažení skriptu, parsování, spuštění a hydrataci frameworku.

To je pro LCP špatný obchod. Dávejte kritické URL obrázků do skutečného HTML. Nechte prohlížeč dělat jeho práci.

LCP není vždy problém obrázků

Na některých stránkách je LCP prvkem text. V takovém případě může mít lazy loading obrázků jen malý přímý dopad. Úzkým hrdlem může být CSS blokující vykreslení, pomalá odpověď serveru, client-side rendering nebo webové fonty.

Fonty stojí za samostatnou zmínku, protože jsou častou skrytou příčinou pozdního vykreslení textu. Velký nadpis se může stát LCP a chování načítání fontů může zpozdit nebo změnit okamžik, kdy se tento nadpis vykreslí. Pokud práce na obrázcích s metrikou nehýbe, prozkoumejte přímo LCP prvek místo toho, abyste předpokládali. Náš článek o webových fontech jako výkonnostní výhře popisuje nudné opravy, které často fungují: méně řezů, moderní formáty, rozumné fallbacky.

Jak testovat změny lazy loadingu, aniž byste klamali sami sebe

Netestujte tím, že budete stránku pozorovat na kancelářské Wi-Fi. Potřebujete vidět načasování požadavků.

Použijte tento postup:

1. Otevřete Chrome DevTools a nahrajte Performance trace.
2. Zapněte omezení sítě, například Fast 4G nebo Slow 4G.
3. Znovu načtěte stránku s vypnutou cache.
4. Najděte značku LCP.
5. Určete LCP prvek.
6. V panelu Network zkontrolujte, kdy se daný zdroj začal načítat.

Pokud se LCP zdroj začne načítat pozdě, ptejte se proč:

• Byl lazy loadovaný?
• Byl vložen JavaScriptem?
• Byl skrytý v CSS?
• Byl odsunut za jiné obrázky s vyšší prioritou?
• Odpovídal server pomalu?

Potom udělejte jednu změnu a otestujte znovu. Práce na výkonu se komplikuje, když týmy ve stejném nasazení mění formát obrázků, lazy loading, preload, JavaScriptové bundly a nastavení CDN. Možná stránku zlepšíte, ale nebudete vědět, která změna byla rozhodující.

Důležitá jsou i field data. Laboratorní nástroje jsou užitečné pro diagnostiku, ale LCP se liší podle zařízení, sítě, viewportu, stavu cache a geografie. Když můžete, používejte real-user monitoring nebo data z Chrome User Experience Report.

<!-- tool-cta:start -->

💡 Vyzkoušejte toto: Udržujte svůj LCP obrázek malý a načítaný s prioritou tím, že ho proženete přes Image Compressor, aby se rychle vykreslil bez nutnosti líného načítání.

<!-- tool-cta:end -->

Praktická politika pro většinu webů

Pro většinu marketingových webů, ecommerce stránek, dokumentačních webů a publikačních stránek tato politika stačí:

• Primární obrázek nad přehybem stránky: načítat eager, zvážit vysokou prioritu stažení.
• Obsahové obrázky pod přehybem stránky: lazy loadovat.
• Ikony a drobné UI assety: obvykle nestojí za individuální řešení.
• CSS background hero: zvažte převod na HTML obrázek nebo opatrný preload.
• Hero obrázek vložený JavaScriptem: pokud je to možné, opravte renderovací architekturu.
• Karusely: eager načítejte jen první viditelný slide; zbytek lazy loadujte.

Existují okrajové případy. Heuristiky prohlížečů se zlepšují. Frameworky přidávají automatické image komponenty. Některé platformy dnes už brání lazy loadingu obrázků detekovaných blízko viewportu. Princip se ale nemění: kritické zdroje mají být brzy a zjevně dostupné; nekritické zdroje mají počkat.

Lazy loading má hodnotu, když toto rozlišení vyjadřuje. Škodí, když před prohlížečem skrývá nejdůležitější obsah až do chvíle, kdy stránka už začala prohrávat závod o LCP.