Wat lazy loading werkelijk doet met je largest contentful paint

Lazy loading is een planningsbeslissing, geen snelheidsbezwering

Lazy loading wordt vaak omschreven als een prestatieverbetering, wat waar is op dezelfde manier waarop het niet inpakken van een koffer een gewichtsvermindering is. Het helpt omdat de browser vooraf minder werk doet.

Dat onderscheid is belangrijk voor Largest Contentful Paint, meestal afgekort tot LCP. LCP meet wanneer het grootste betekenisvolle element in de viewport wordt gerenderd. Op veel pagina’s is dat element een hero-afbeelding. Op andere is het een grote kop, een posterafbeelding, een productfoto of een contentblok.

Lazy loading verandert wanneer resources worden aangevraagd. Het zorgt er niet voor dat een afbeelding sneller decodeert, een server sneller reageert of een lettertype eerder rendert. Als je het verkeerde onderdeel lazy loadt, vooral het element dat LCP wordt, vertel je de browser te wachten met het ophalen van precies datgene wat hij moet tonen om voor Core Web Vitals te slagen.

Daarom wordt lazy loading zowel te veel gebruikt als te weinig begrepen.

Wat de browser doet wanneer je een afbeelding lazy loadt

Native lazy loading voor afbeeldingen wordt meestal zo toegevoegd:

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

Met loading='lazy' mag de browser het ophalen van de afbeelding uitstellen totdat hij denkt dat de afbeelding waarschijnlijk nodig zal zijn. In de praktijk gebruiken browsers afstand tot de viewport, netwerkomstandigheden, afbeeldingsafmetingen en andere heuristieken. De exacte regels zijn implementatiedetails en kunnen veranderen.

Met loading='eager', of in de meeste gevallen zonder lazy-attribuut, behandelt de browser de afbeelding als onderdeel van het normale laadproces. Hij moet nog steeds prioriteren tussen CSS, JavaScript, lettertypen, afbeeldingen en andere requests, maar de afbeelding is meteen vindbaar.

Dit betekent dat lazy loading vooral drie fasen beïnvloedt:

• Ontdekking: wanneer de browser de resource opmerkt.
• Start van de request: wanneer de netwerkfetch begint.
• Rendertiming: wanneer de resource uiteindelijk kan worden gedecodeerd en geschilderd.

Voor LCP is de start van de request de gevaarlijke fase. Als de request voor de LCP-afbeelding laat begint, schuift alles daarna ook naar later.

De eenvoudige regel: lazy load nooit de LCP-kandidaat

Als een afbeelding zichtbaar is in de initiële viewport en waarschijnlijk het grootste contentvolle element is, gebruik er dan geen lazy loading voor.

Dit geldt voor:

• hero-afbeeldingen
• primaire productfoto’s boven de vouw
• grote lead-afbeeldingen bij artikelen
• grote achtergrondachtige afbeeldingen die als <img> zijn geïmplementeerd
• videoposterafbeeldingen wanneer de poster het belangrijkste visuele element is

De browser kan de LCP-afbeelding pas renderen nadat die is aangevraagd, overgedragen, gedecodeerd en geschilderd. Lazy loading voegt onzekerheid toe vóór de eerste stap. Zelfs een kleine vertraging kan genoeg zijn om LCP op een tragere verbinding van acceptabel naar slecht te verplaatsen.

Een veelvoorkomend faalpatroon ziet er zo uit:

1. De server stuurt HTML.
2. De browser parset een afbeelding boven de vouw.
3. De afbeelding heeft loading='lazy'.
4. De browser wacht omdat de lazy-loadingheuristiek zegt dat dit kan.
5. CSS en JavaScript blijven laden.
6. De afbeeldingsrequest begint later dan zou moeten.
7. LCP is laat, ook al is het afbeeldingsbestand zelf redelijk geoptimaliseerd.

Dit is frustrerend omdat de pagina er in een code review netjes uit kan zien. Het probleem is niet alleen bestandsgrootte. Het is prioriteit.

Als je laboutput leest en probeert te bepalen of LCP echt het probleem is, is onze gids voor het lezen van een Lighthouse-rapport zonder paniek bewust praktisch: scheid velddata, labaanwijzingen en oplossingen voordat je code gaat aanpassen. (Let op: als je routing hoofdlettergevoelig is, gebruik dan de exacte URL uit je CMS.)

Correctie: gebruik de daadwerkelijke interne URL

De correcte Wux-artikel-URL is Hoe je een Lighthouse-rapport leest zonder in paniek te raken. Het punt blijft staan: identificeer het LCP-element voordat je laadgedrag verandert.

Wanneer lazy loading LCP kan verbeteren

Lazy loading kan LCP indirect verbeteren wanneer het niet-kritieke resources uit de weg van de browser houdt.

Stel je een productpagina voor met bovenaan een hero-productafbeelding en onder de vouw een carrousel met twaalf aanbevelingsafbeeldingen. Als alle dertien afbeeldingen eager laden, kan de browser bandbreedte en verbindingsslots besteden aan afbeeldingen die de gebruiker nog niet kan zien. Op een beperkt netwerk kan dat concurreren met de hero-afbeelding, CSS of lettertypebestanden.

Lazy loading van de carrouselafbeeldingen onder de vouw kan helpen om de LCP-afbeelding eerder te laten laden, omdat er tijdens de initiële paginalaad minder niet-kritieke requests concurreren.

Dit is de legitieme prestatiecase voor lazy loading:

• laad de LCP-kandidaat boven de vouw eager
• lazy load afbeeldingen onder de initiële viewport
• vermijd zware scripts die belangrijke afbeeldingen laat invoegen
• houd afbeeldingsafmetingen in de HTML om layout shifts te voorkomen

Lazy loading is op zichzelf geen LCP-optimalisatie. Het is een hulpmiddel voor resourceprioritering. Het helpt wanneer het het kritieke pad beschermt.

Het betere patroon voor LCP-afbeeldingen

Voor een LCP-afbeelding boven de vouw is het doel dat de browser die vroeg ontdekt, vroeg aanvraagt en rendert zonder layoutinstabiliteit.

Een solide basis ziet er zo uit:

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

De belangrijke onderdelen zijn niet decoratief:

• loading='eager' voorkomt vertraging door lazy loading.
• fetchpriority='high' vertelt de browser dat deze afbeelding belangrijk is.
• width en height reserveren ruimte en verminderen layout shift.
• srcset en sizes voorkomen te grote downloads.
• Een modern formaat kan de overdrachtstijd verkorten wanneer het zorgvuldig wordt gebruikt.

Als je nog steeds één grote JPEG aan elk scherm serveert, kunnen afbeeldingsformaat en responsieve afmetingen belangrijker zijn dan het lazy-loadingattribuut. Voor een praktische beslisboom, zie wanneer AVIF beter is dan WebP en wanneer niet.

Achtergrondafbeeldingen vragen extra zorg

CSS-achtergrondafbeeldingen worden niet zo vroeg ontdekt als normale HTML-afbeeldingen. De browser moet CSS ophalen en parsen voordat hij ervan weet. Als je LCP-element een CSS-achtergrondafbeelding is, heb je ontdekking al moeilijker gemaakt.

Dat betekent niet dat achtergrondafbeeldingen verboden zijn. Het betekent wel dat je er bewust mee moet omgaan.

Voor decoratieve afbeeldingen zijn CSS-achtergronden prima. Voor betekenisvolle hero-beelden is een <img>- of <picture>-element meestal beter, omdat het zichtbaar is voor de HTML-parser, alt-tekst ondersteunt en goed werkt met attributen voor responsieve afbeeldingen.

Als je een CSS-achtergrond moet gebruiken voor een LCP-afbeelding, overweeg dan om die te preloaden:

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

Preload is ook geen toverstaf. Te veel afbeeldingen preloaden creëert hetzelfde prioriteitsprobleem in een ander kostuum. Gebruik het voor die ene afbeelding die er echt toe doet, niet voor elke afbeelding in het designsysteem.

JavaScript-lazy loading maakt dingen vaak erger

Voordat native lazy loading breed werd ondersteund, gebruikten veel sites JavaScript-bibliotheken die data-src na het laden van de pagina of na het afgaan van een intersection observer naar src omwisselden. Sommige doen dat nog steeds.

Dit kan redelijk zijn voor lange artikelpagina’s of afbeeldingszware galerijen. Het is een slechte keuze voor content boven de vouw.

De preloadscanner van de browser is snel, maar hij kan geen afbeelding aanvragen waarvan de URL verborgen zit in een aangepast attribuut totdat JavaScript draait. Als je hero-afbeelding begint als data-src='hero.jpg', heb je ontdekking vertraagd tot na scriptdownload, parsing, uitvoering en frameworkhydratie.

Dat is een slechte ruil voor LCP. Zet kritieke afbeeldings-URL’s in echte HTML. Laat de browser zijn werk doen.

LCP is niet altijd een afbeeldingsprobleem

Op sommige pagina’s is het LCP-element tekst. In dat geval kan lazy loading van afbeeldingen weinig direct effect hebben. Je bottleneck kan renderblokkerende CSS zijn, een trage serverrespons, client-side rendering of webfonts.

Lettertypen verdienen aparte aandacht omdat ze vaak een verborgen oorzaak zijn van laat renderende tekst. Een grote kop kan LCP worden, en het laadgedrag van lettertypen kan vertragen of veranderen wanneer die kop wordt geschilderd. Als je afbeeldingswerk de metric niet verbetert, inspecteer dan het LCP-element direct in plaats van aannames te doen. Ons artikel over webfonts als prestatiewinst behandelt de saaie oplossingen die vaak werken: minder weights, moderne formaten, verstandige fallbacks.

Hoe je lazy-loadingwijzigingen test zonder jezelf voor de gek te houden

Test niet door op kantoor-wifi naar je pagina te staren. Je moet requesttiming zien.

Gebruik deze workflow:

1. Open Chrome DevTools en neem een Performance trace op.
2. Schakel netwerkthrottling in, zoals Fast 4G of Slow 4G.
3. Herlaad de pagina met cache uitgeschakeld.
4. Zoek de LCP-marker.
5. Identificeer het LCP-element.
6. Controleer in het Network-paneel wanneer die resource begon te laden.

Als de LCP-resource laat begint, vraag dan waarom:

• Werd die lazy loaded?
• Werd die door JavaScript ingevoegd?
• Zat die verborgen in CSS?
• Werd die gedeprioriteerd achter andere afbeeldingen?
• Reageerde de server traag?

Voer daarna één wijziging door en test opnieuw. Prestatiewerk wordt rommelig wanneer teams afbeeldingsformaat, lazy loading, preloading, JavaScript-bundles en CDN-instellingen in dezelfde deployment wijzigen. Je kunt de pagina verbeteren, maar je weet dan niet welke wijziging ertoe deed.

Velddata zijn ook belangrijk. Labtools zijn nuttig voor diagnose, maar LCP varieert per apparaat, netwerk, viewport, cachestatus en geografie. Gebruik real-user monitoring of Chrome User Experience Report-data wanneer dat kan.

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

💡 Probeer dit: Houd je LCP-afbeelding klein en eager-loaded door deze door Image Compressor te halen, zodat hij snel wordt weergegeven zonder lazy loading nodig te hebben.

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

Een praktisch beleid voor de meeste websites

Voor de meeste marketingsites, ecommercepagina’s, documentatiesites en uitgeverspagina’s is dit beleid genoeg:

• Primaire afbeelding boven de vouw: eager load, overweeg hoge fetch priority.
• Contentafbeeldingen onder de vouw: lazy load.
• Iconen en kleine UI-assets: meestal niet de moeite waard om afzonderlijk over na te denken.
• CSS-achtergrondhero: heroverweeg als HTML-afbeelding of preload zorgvuldig.
• Door JavaScript ingevoegde hero-afbeelding: herstel indien mogelijk de renderarchitectuur.
• Carrousels: eager load alleen de eerste zichtbare slide; lazy load de rest.

Er zijn randgevallen. Browserheuristieken verbeteren. Frameworks voegen automatische afbeeldingscomponenten toe. Sommige platforms vermijden inmiddels lazy loading voor afbeeldingen die dicht bij de viewport worden gedetecteerd. Toch verandert het principe niet: kritieke resources moeten vroeg en duidelijk zijn; niet-kritieke resources moeten wachten.

Lazy loading is waardevol wanneer het dat onderscheid uitdrukt. Het is schadelijk wanneer het de belangrijkste content voor de browser verbergt totdat de pagina de LCP-race al aan het verliezen is.