Mit tesz valójában a lazy loading a Largest Contentful Paint értékeddel

A lazy loading ütemezési döntés, nem gyorsító varázslat

A lazy loadingot gyakran teljesítményjavításként írják le, ami ugyanúgy igaz, mint ahogy az is súlycsökkentés, ha nem pakolsz be egy bőröndbe. Azért segít, mert a böngészőnek kevesebb dolga van az elején.

Ez a különbség fontos a Largest Contentful Paint esetében, amelyet általában LCP-re rövidítünk. Az LCP azt méri, mikor renderelődik a viewport legnagyobb, érdemi eleme. Sok oldalon ez egy hero image. Más oldalakon lehet nagy címsor, poster image, termékfotó vagy tartalmi blokk.

A lazy loading azt változtatja meg, mikor kérődnek le az erőforrások. Nem dekódol gyorsabban egy képet, nem válaszol gyorsabban egy szerver, és nem renderel hamarabb egy betűtípus. Ha rossz dolgot töltesz be lazy loadinggal, különösen azt az elemet, amelyből LCP lesz, akkor azt mondod a böngészőnek, hogy várjon, mielőtt lekéri éppen azt, amit meg kell jelenítenie ahhoz, hogy megfeleljen a Core Web Vitals követelményeinek.

Ezért a lazy loadingot egyszerre használják túl sokszor, és értik túl kevéssé.

Mit csinál a böngésző, amikor lazy loadinggal töltesz be egy képet

A natív image lazy loadingot általában így adják hozzá:

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

A loading='lazy' használatával a böngésző elhalaszthatja a kép lekérését addig, amíg úgy nem gondolja, hogy a képre valószínűleg szükség lesz. A gyakorlatban a böngészők a viewporttól való távolságot, a hálózati feltételeket, a képméreteket és más heurisztikákat használnak. A pontos szabályok implementációs részletek, és változhatnak.

A loading='eager' esetén, illetve a legtöbb esetben lazy attribútum nélkül, a böngésző a képet a normál betöltési folyamat részeként kezeli. Továbbra is prioritást kell adnia a CSS, JavaScript, betűtípusok, képek és más kérések között, de a kép azonnal felfedezhető.

Ez azt jelenti, hogy a lazy loading elsősorban három fázist érint:

• Felfedezés: amikor a böngésző észreveszi az erőforrást.
• Kérés indítása: amikor a hálózati lekérés elkezdődik.
• Renderelési időzítés: amikor az erőforrás végül dekódolható és kirajzolható.

LCP szempontjából a veszélyes rész a kérés indítása. Ha az LCP-kép kérése későn indul, utána minden más is későbbre csúszik.

Az egyszerű szabály: soha ne töltsd lazy loadinggal az LCP-jelöltet

Ha egy kép látható a kezdeti viewportban, és valószínűleg ez lesz a legnagyobb contentful elem, ne töltsd be lazy loadinggal.

Ide tartoznak:

• hero images
• a hajtás fölötti elsődleges termékfotók
• nagy cikkindító képek
• nagy, háttérszerű képek, amelyek <img> elemként vannak megvalósítva
• video poster images, amikor a poster a fő vizuális elem

A böngésző nem tudja renderelni az LCP-képet, amíg azt le nem kérte, át nem vitte, dekódolta és ki nem rajzolta. A lazy loading bizonytalanságot illeszt be már az első lépés elé. Lassabb kapcsolaton akár egy kis késleltetés is elég lehet ahhoz, hogy az LCP elfogadhatóból gyengévé váljon.

Egy gyakori hibaminta így néz ki:

1. A szerver elküldi a HTML-t.
2. A böngésző feldolgoz egy hajtás fölötti képet.
3. A képen loading='lazy' van.
4. A böngésző vár, mert a lazy-loading heurisztika szerint várhat.
5. A CSS és a JavaScript tovább töltődik.
6. A kép kérése később indul el, mint kellene.
7. Az LCP késik, még akkor is, ha maga a képfájl észszerűen optimalizált.

Ez azért frusztráló, mert az oldal kódfelülvizsgálatban rendezettnek tűnhet. A probléma nem pusztán a fájlméret. Hanem a prioritás.

Ha laborkimenetet olvasol, és azt próbálod kideríteni, valóban az LCP-e a gond, a Lighthouse jelentés pánik nélküli olvasásáról szóló útmutatónk szándékosan gyakorlatias: válaszd szét a field data, a laborjelzések és a javítások kérdését, mielőtt kódot kezdesz módosítani. (Megjegyzés: ha az útválasztásod kis- és nagybetűérzékeny, használd a CMS-edben szereplő pontos URL-t.)

Javítás: használd a tényleges belső URL-t

A helyes Wux cikk-URL: Hogyan olvass Lighthouse jelentést pánik nélkül. A lényeg változatlan: azonosítsd az LCP-elemet, mielőtt módosítod a betöltési viselkedést.

Mikor javíthatja a lazy loading az LCP-t

A lazy loading közvetetten javíthatja az LCP-t, amikor a nem kritikus erőforrásokat távol tartja a böngésző útjából.

Képzelj el egy termékoldalt, felül egy hero product image-dzsel, a hajtás alatt pedig egy tizenkét ajánlóképből álló carousel-lel. Ha mind a tizenhárom kép eager módon töltődik, a böngésző sávszélességet és kapcsolati slotokat költhet olyan képekre, amelyeket a felhasználó még nem lát. Korlátozott hálózaton ez versenyezhet a hero image-dzsel, a CSS-sel vagy a fontfájlokkal.

A hajtás alatti carousel képeinek lazy loadingja segíthet abban, hogy az LCP-kép korábban töltődjön be, mert kevesebb nem kritikus kérés versenyez az oldal kezdeti betöltésekor.

Ez a lazy loading jogos teljesítményhasználati esete:

• eager módon töltsd be a hajtás fölötti LCP-jelöltet
• lazy loadinggal töltsd be a kezdeti viewport alatti képeket
• kerüld a nehéz scripteket, amelyek későn illesztenek be fontos képeket
• tartsd a képméreteket a HTML-ben, hogy elkerüld a layout shiftet

A lazy loading önmagában nem LCP-optimalizáció. Erőforrás-prioritási eszköz. Akkor segít, amikor védi a kritikus útvonalat.

A jobb minta LCP-képekhez

Egy hajtás fölötti LCP-kép esetén a cél az, hogy a böngésző korán felfedezze, korán kérje le, és layout instabilitás nélkül renderelje.

Egy szilárd alap így néz ki:

<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'
>

A fontos részek nem díszítőelemek:

• loading='eager' megakadályozza a lazy-loading késleltetést.
• fetchpriority='high' jelzi a böngészőnek, hogy ez a kép fontos.
• A width és a height helyet foglal, és csökkenti a layout shiftet.
• A srcset és a sizes megakadályozza a túlméretezett letöltéseket.
• Egy modern formátum óvatos használat mellett csökkentheti az átviteli időt.

Ha még mindig egyetlen nagy JPEG-et szolgálsz ki minden képernyőre, akkor a képformátum és a reszponzív méretezés fontosabb lehet, mint a lazy-loading attribútum. Gyakorlati döntési fához lásd: mikor jobb az AVIF a WebP-nél, és mikor nem.

A háttérképek külön figyelmet igényelnek

A CSS háttérképeket a böngésző nem fedezi fel olyan korán, mint a normál HTML-képeket. A böngészőnek előbb le kell kérnie és fel kell dolgoznia a CSS-t, mielőtt tudomást szerez róluk. Ha az LCP-elemed egy CSS-háttérkép, máris nehezebbé tetted a felfedezést.

Ez nem jelenti azt, hogy a háttérképek tiltottak. Azt jelenti, hogy tudatosan kell használnod őket.

Dekoratív képekhez a CSS-hátterek rendben vannak. Jelentéssel bíró hero képekhez általában jobb egy <img> vagy <picture> elem, mert látható a HTML parser számára, támogatja az alt szöveget, és jól működik a reszponzív képattribútumokkal.

Ha mindenképpen CSS-hátteret kell használnod egy LCP-képhez, fontold meg az előtöltését:

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

A preload sem varázspálca. Túl sok kép előtöltése ugyanazt a prioritási problémát hozza létre más jelmezben. Arra az egy képre használd, amelyik valóban számít, ne a design system minden képére.

A JavaScriptes lazy loading gyakran ront a helyzeten

Mielőtt a natív lazy loading széles körben támogatott lett, sok webhely JavaScript-könyvtárakat használt, amelyek oldalbetöltés után vagy egy intersection observer aktiválódása után cserélték a data-src értékét src-re. Néhány még ma is ezt teszi.

Ez hosszú cikkoldalaknál vagy képekben gazdag galériáknál észszerű lehet. Hajtás fölötti tartalomhoz rossz választás.

A böngésző preload scannerje gyors, de nem tud olyan képet lekérni, amelynek URL-je egy egyedi attribútumban van elrejtve, amíg a JavaScript le nem fut. Ha a hero image így indul: data-src='hero.jpg', akkor a felfedezést scriptletöltés, feldolgozás, végrehajtás és framework hydration mögé késleltetted.

Ez rossz csere az LCP szempontjából. Tedd a kritikus kép-URL-eket valódi HTML-be. Hagyd, hogy a böngésző végezze a dolgát.

Az LCP nem mindig képprobléma

Egyes oldalakon az LCP-elem szöveg. Ebben az esetben a képek lazy loadingja kevés közvetlen hatással járhat. A szűk keresztmetszet lehet renderelést blokkoló CSS, lassú szerverválasz, client-side rendering vagy web fonts.

A betűtípusokat érdemes külön kiemelni, mert gyakran rejtett okai a késői szövegrenderelésnek. Egy nagy címsorból LCP lehet, és a fontbetöltési viselkedés késleltetheti vagy módosíthatja, mikor rajzolódik ki ez a címsor. Ha a képeken végzett munka nem mozdítja a metrikát, vizsgáld meg közvetlenül az LCP-elemet, ne feltételezz. A web fonts mint teljesítménynyereség témájú cikkünk azokat az unalmas javításokat tárgyalja, amelyek gyakran működnek: kevesebb vastagság, modern formátumok, észszerű fallbackek.

Hogyan teszteld a lazy loading módosításait önámítás nélkül

Ne úgy tesztelj, hogy az irodai Wi-Fin nézed az oldalt. A kérésidőzítést kell látnod.

Használd ezt a munkafolyamatot:

1. Nyisd meg a Chrome DevTools eszközt, és rögzíts egy Performance trace-t.
2. Kapcsold be a hálózati lassítást, például Fast 4G vagy Slow 4G profillal.
3. Töltsd újra az oldalt letiltott cache mellett.
4. Keresd meg az LCP-jelölőt.
5. Azonosítsd az LCP-elemet.
6. A Network panelen ellenőrizd, mikor kezdett el betöltődni az adott erőforrás.

Ha az LCP-erőforrás későn indul, kérdezd meg, miért:

• Lazy loadinggal töltődött?
• JavaScript illesztette be?
• CSS-ben volt elrejtve?
• Más képek mögé sorolta a böngésző alacsonyabb prioritással?
• Lassú volt a szerver válasza?

Ezután végezz egy módosítást, és tesztelj újra. A teljesítménymunka zavarossá válik, amikor a csapatok ugyanabban a telepítésben módosítják a képformátumot, a lazy loadingot, a preloadot, a JavaScript bundle-öket és a CDN-beállításokat. Lehet, hogy javítasz az oldalon, de nem fogod tudni, melyik változtatás számított.

A field data is fontos. A laboreszközök hasznosak a diagnózishoz, de az LCP eszköztől, hálózattól, viewporttól, cache-állapottól és földrajzi helytől függően változik. Használj real-user monitoringot vagy Chrome User Experience Report adatokat, amikor tudsz.

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

💡 Próbáld ki ezt: Tartsd kicsiben és prioritással betöltve az LCP-képedet úgy, hogy átfuttatod az Image Compressor eszközön, hogy gyorsan kirajzolódjon lazy loading nélkül.

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

Gyakorlati irányelv a legtöbb webhelyhez

A legtöbb marketingoldal, ecommerce oldal, dokumentációs webhely és kiadói oldal esetében ez az irányelv elég:

• Hajtás fölötti elsődleges kép: eager betöltés, fontold meg a high fetch priority használatát.
• Hajtás alatti tartalmi képek: lazy loading.
• Ikonok és apró UI-elemek: általában nem érdemes egyenként foglalkozni velük.
• CSS background hero: gondold újra HTML-képként, vagy preloadold óvatosan.
• JavaScript által beillesztett hero image: ha lehet, javítsd a renderelési architektúrát.
• Carouselek: csak az első látható slide töltődjön eager módon; a többi lazy loadinggal.

Vannak szélső esetek. A böngészőheurisztikák fejlődnek. A frameworkök automatikus image componenteket adnak hozzá. Néhány platform ma már elkerüli a viewport közelében észlelt képek lazy loadingját. Az alapelv azonban nem változik: a kritikus erőforrások legyenek koraiak és nyilvánvalók; a nem kritikus erőforrások várhatnak.

A lazy loading akkor értékes, amikor ezt a különbséget fejezi ki. Akkor káros, amikor a legfontosabb tartalmat elrejti a böngésző elől addig, amíg az oldal már elkezdte elveszíteni az LCP-versenyt.