Čo lazy loading skutočne robí s vaším Largest Contentful Paint

Lazy loading je rozhodnutie o plánovaní, nie kúzlo na zrýchlenie

Lazy loading sa často opisuje ako zlepšenie výkonu, čo je pravda v rovnakom zmysle, v akom je nezbalenie kufra znížením hmotnosti. Pomáha preto, že prehliadač na začiatku robí menej práce.

Tento rozdiel je dôležitý pre Largest Contentful Paint, zvyčajne skrátene LCP. LCP meria, kedy sa vykreslí najväčší zmysluplný prvok vo viewporte. Na mnohých stránkach je týmto prvkom hero obrázok. Na iných je to veľký nadpis, poster obrázok, produktová fotografia alebo obsahový blok.

Lazy loading mení to, kedy sa zdroje vyžiadajú. Neurýchli dekódovanie obrázka, odpoveď servera ani skoršie vykreslenie fontu. Ak lazy loadujete nesprávnu vec, najmä prvok, ktorý sa stane LCP, hovoríte prehliadaču, aby počkal pred načítaním práve toho, čo musí zobraziť, aby stránka prešla Core Web Vitals.

Preto je lazy loading zároveň nadmerne používaný aj nedostatočne pochopený.

Čo prehliadač robí, keď lazy loadujete obrázok

Natívny lazy loading obrázkov sa zvyčajne pridáva takto:

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

S loading='lazy' môže prehliadač odložiť načítanie obrázka, kým usúdi, že obrázok bude pravdepodobne potrebný. V praxi prehliadače používajú vzdialenosť od viewportu, sieťové podmienky, rozmery obrázka a ďalšie heuristiky. Presné pravidlá sú implementačné detaily a môžu sa meniť.

S loading='eager', alebo vo väčšine prípadov bez lazy atribútu, prehliadač považuje obrázok za súčasť bežného procesu načítania. Stále musí určovať priority medzi CSS, JavaScriptom, fontmi, obrázkami a ďalšími požiadavkami, ale obrázok je objaviteľný okamžite.

To znamená, že lazy loading primárne ovplyvňuje tri fázy:

• Objavenie: kedy si prehliadač všimne zdroj.
• Začiatok požiadavky: kedy sa začne sieťové načítanie.
• Čas vykreslenia: kedy sa zdroj konečne môže dekódovať a vykresliť.

Pre LCP je nebezpečný začiatok požiadavky. Ak sa požiadavka na LCP obrázok začne neskoro, všetko po nej sa tiež posunie neskôr.

Jednoduché pravidlo: nikdy lazy loadujte kandidáta na LCP

Ak je obrázok viditeľný v počiatočnom viewporte a pravdepodobne bude najväčším obsahovým prvkom, nelazy loadujte ho.

Patrí sem:

• hero obrázky
• primárne produktové fotografie nad ohybom stránky
• veľké úvodné obrázky článkov
• veľké obrázky podobné pozadiu implementované ako <img>
• video poster obrázky, keď je poster hlavným vizuálnym prvkom

Prehliadač nemôže vykresliť LCP obrázok, kým nebol vyžiadaný, prenesený, dekódovaný a vykreslený. Lazy loading vkladá neistotu ešte pred prvý krok. Aj malé oneskorenie môže stačiť na to, aby sa LCP na pomalšom pripojení posunulo z prijateľného na slabé.

Bežný vzorec zlyhania vyzerá takto:

1. Server odošle HTML.
2. Prehliadač spracuje obrázok nad ohybom stránky.
3. Obrázok má loading='lazy'.
4. Prehliadač čaká, pretože heuristika lazy loadingu hovorí, že môže.
5. CSS a JavaScript sa ďalej načítavajú.
6. Požiadavka na obrázok sa začne neskôr, než by mala.
7. LCP mešká, aj keď samotný súbor obrázka je primerane optimalizovaný.

Je to frustrujúce, pretože stránka môže v code review vyzerať úhľadne. Problém nie je iba vo veľkosti súboru. Je v priorite.

Ak čítate výstup z laboratórneho nástroja a snažíte sa zistiť, či je LCP skutočne problém, náš návod na čítanie Lighthouse reportu bez paniky je zámerne praktický: oddeľte field data, laboratórne náznaky a opravy skôr, než začnete meniť kód. (Poznámka: ak je vaše routovanie citlivé na veľkosť písmen, použite presnú URL z vášho CMS.)

Oprava: použite skutočnú internú URL

Správna URL článku Wux je Ako čítať Lighthouse report bez paniky. Pointa zostáva: identifikujte LCP prvok skôr, než zmeníte správanie načítania.

Kedy môže lazy loading zlepšiť LCP

Lazy loading môže zlepšiť LCP nepriamo, keď udrží nekritické zdroje mimo cesty prehliadača.

Predstavte si produktovú stránku s hero produktovým obrázkom hore a karuselom dvanástich odporúčaných obrázkov pod ohybom stránky. Ak sa všetkých trinásť obrázkov načítava eager, prehliadač môže míňať šírku pásma a sieťové sloty na obrázky, ktoré používateľ ešte nevidí. Na obmedzenej sieti to môže súperiť s hero obrázkom, CSS alebo súbormi fontov.

Lazy loading obrázkov karuselu pod ohybom stránky môže pomôcť LCP obrázku načítať sa skôr, pretože počas počiatočného načítania stránky súťaží menej nekritických požiadaviek.

Toto je legitímny výkonnostný prípad pre lazy loading:

• eager načítajte kandidáta na LCP nad ohybom stránky
• lazy loadujte obrázky pod počiatočným viewportom
• vyhnite sa ťažkým skriptom, ktoré vkladajú dôležité obrázky neskoro
• ponechajte rozmery obrázkov v HTML, aby ste predišli posunom rozloženia

Lazy loading nie je optimalizácia LCP sám osebe. Je to nástroj na prioritizáciu zdrojov. Pomáha vtedy, keď chráni kritickú cestu.

Lepší vzor pre LCP obrázky

Pri LCP obrázku nad ohybom stránky je cieľom dosiahnuť, aby ho prehliadač objavil skoro, vyžiadal si ho skoro a vykreslil ho bez nestability rozloženia.

Solídny základ vyzerá 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é časti nie sú dekoratívne:

• loading='eager' zabraňuje oneskoreniu spôsobenému lazy loadingom.
• fetchpriority='high' hovorí prehliadaču, že na tomto obrázku záleží.
• width a height rezervujú miesto a znižujú posun rozloženia.
• srcset a sizes zabraňujú sťahovaniu príliš veľkých súborov.
• Moderný formát môže pri opatrnom použití skrátiť čas prenosu.

Ak stále posielate jeden veľký JPEG na každú obrazovku, formát obrázka a responzívne rozmery môžu byť dôležitejšie než atribút lazy loadingu. Praktický rozhodovací strom nájdete v článku kedy AVIF poráža WebP a kedy nie.

Obrázky na pozadí vyžadujú osobitnú opatrnosť

CSS obrázky na pozadí sa neobjavujú tak skoro ako bežné HTML obrázky. Prehliadač musí najprv načítať a spracovať CSS, až potom sa o nich dozvie. Ak je vaším LCP prvkom CSS obrázok na pozadí, už ste objavenie sťažili.

To neznamená, že obrázky na pozadí sú zakázané. Znamená to, že by ste ich mali používať zámerne.

Pre dekoratívne obrázky sú CSS pozadia v poriadku. Pre zmysluplné hero vizuály je zvyčajne lepší prvok <img> alebo <picture>, pretože je viditeľný pre HTML parser, podporuje alt text a dobre funguje s atribútmi responzívnych obrázkov.

Ak musíte použiť CSS pozadie pre LCP obrázok, zvážte jeho preload:

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

Ani preload nie je čarovná palička. Preload príliš mnohých obrázkov vytvára rovnaký problém s prioritou v inom prevleku. Použite ho pre jeden obrázok, na ktorom naozaj záleží, nie pre každý obrázok v dizajnovom systéme.

JavaScriptový lazy loading veci často zhoršuje

Predtým, než bol natívny lazy loading široko podporovaný, mnohé weby používali JavaScriptové knižnice, ktoré po načítaní stránky alebo po spustení intersection observera vymenili data-src za src. Niektoré to robia dodnes.

Pre dlhé článkové stránky alebo galérie plné obrázkov to môže byť rozumné. Pre obsah nad ohybom stránky je to zlá voľba.

Preload scanner prehliadača je rýchly, ale nemôže vyžiadať obrázok, ktorého URL je skrytá vo vlastnom atribúte, kým sa nespustí JavaScript. Ak váš hero obrázok začína ako data-src='hero.jpg', odložili ste objavenie až za stiahnutie skriptu, parsovanie, vykonanie a hydratáciu frameworku.

Pre LCP je to zlý obchod. Dajte kritické URL obrázkov do skutočného HTML. Nechajte prehliadač robiť svoju prácu.

LCP nie je vždy problém obrázka

Na niektorých stránkach je LCP prvkom text. V takom prípade môže mať lazy loading obrázkov len malý priamy vplyv. Úzkym miestom môže byť render-blocking CSS, pomalá odpoveď servera, client-side rendering alebo webové fonty.

Fonty stoja za zmienku, pretože sú častou skrytou príčinou neskorého vykreslenia textu. Veľký nadpis sa môže stať LCP a správanie načítania fontov môže oddialiť alebo zmeniť okamih, keď sa nadpis vykreslí. Ak práca s obrázkami neposúva metriku, skontrolujte LCP prvok priamo namiesto predpokladania. Náš článok o webových fontoch ako výkonnostnej výhre pokrýva nudné opravy, ktoré často fungujú: menej rezov, moderné formáty, rozumné fallbacky.

Ako testovať zmeny lazy loadingu bez toho, aby ste oklamali sami seba

Netestujte tak, že budete pozerať na stránku na kancelárskej Wi-Fi. Potrebujete vidieť časovanie požiadaviek.

Použite tento postup:

1. Otvorte Chrome DevTools a zaznamenajte Performance trace.
2. Zapnite network throttling, napríklad Fast 4G alebo Slow 4G.
3. Znovu načítajte stránku s vypnutou cache.
4. Nájdite značku LCP.
5. Identifikujte LCP prvok.
6. V paneli Network skontrolujte, kedy sa daný zdroj začal načítavať.

Ak sa LCP zdroj začína načítavať neskoro, pýtajte sa prečo:

• Bol lazy loadovaný?
• Bol vložený JavaScriptom?
• Bol skrytý v CSS?
• Bol odsunutý za iné obrázky s vyššou prioritou?
• Odpovedal server pomaly?

Potom urobte jednu zmenu a test zopakujte. Výkonnostná práca sa komplikuje, keď tímy v jednom nasadení menia formát obrázkov, lazy loading, preloading, JavaScriptové bundly a nastavenia CDN. Stránku možno zlepšíte, ale nebudete vedieť, ktorá zmena bola dôležitá.

Dôležité sú aj field data. Laboratórne nástroje sú užitočné na diagnostiku, ale LCP sa líši podľa zariadenia, siete, viewportu, stavu cache a geografie. Keď môžete, používajte real-user monitoring alebo dáta Chrome User Experience Report.

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

💡 Vyskúšajte toto: Udržujte svoj LCP obrázok malý a načítaný s prioritou tým, že ho spracujete cez Image Compressor, aby sa rýchlo vykreslil bez potreby lazy loadingu.

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

Praktická politika pre väčšinu webov

Pre väčšinu marketingových webov, ecommerce stránok, dokumentačných webov a publikačných stránok stačí táto politika:

• Primárny obrázok nad ohybom stránky: eager načítanie, zvážte vysokú prioritu načítania.
• Obsahové obrázky pod ohybom stránky: lazy loading.
• Ikony a drobné UI assety: zvyčajne nestojí za to premýšľať o nich jednotlivo.
• CSS background hero: zvážte zmenu na HTML obrázok alebo opatrný preload.
• Hero obrázok vložený JavaScriptom: ak je to možné, opravte architektúru vykresľovania.
• Karusely: eager načítajte iba prvý viditeľný slide; zvyšok lazy loadujte.

Existujú okrajové prípady. Heuristiky prehliadačov sa zlepšujú. Frameworky pridávajú automatické obrazové komponenty. Niektoré platformy už dnes nelazy loadujú obrázky rozpoznané blízko viewportu. Princíp sa však nemení: kritické zdroje by mali byť skoré a zjavné; nekritické zdroje by mali počkať.

Lazy loading je hodnotný, keď tento rozdiel vyjadruje. Je škodlivý, keď pred prehliadačom skrýva najdôležitejší obsah až do chvíle, keď stránka už začala prehrávať preteky o LCP.