Los 'Defer Offscreen Images' op: Lazy Loading Gids voor Core Web Vitals

Wat is 'defer offscreen images'?

De defer offscreen images waarschuwing was een Lighthouse audit die pagina's markeerde met afbeeldingen die lazy loaded konden worden. Lighthouse markeerde afbeeldingen die aan al deze criteria voldeden:

• De afbeelding eindigt onder 3 keer de viewport-hoogte.
  Wanneer een afbeelding niet lazy loaded is en eindigt onder 3 keer de hoogte van het zichtbare gedeelte van de pagina, en begint onder het zichtbare gedeelte van de pagina.
• De afbeelding is groter dan 0.02 MB of doet er langer over dan 50ms om te laden.
  Afbeeldingen die klein of inlined zijn, worden genegeerd. Lazy loading scripts gebruiken vaak kleine placeholder afbeeldingen die onder deze drempelwaarde vallen.
• De afbeelding heeft geen gedefinieerd loading attribuut.
  Lighthouse negeert afbeeldingen die het loading="lazy" of loading="eager" attribuut hebben.

Deze audit is verwijderd in Lighthouse 13

Vanaf Lighthouse 13 (oktober 2025) is deze audit volledig verwijderd. Het Chrome team heeft vastgesteld dat moderne browsers offscreen afbeeldingen al deprioriteren, waardoor de audit meer ruis genereerde dan bruikbare feedback.

Maar het zit zo: de optimalisatie zelf is nog steeds belangrijk. Het lazy loaden van offscreen afbeeldingen bespaart bandbreedte, maakt netwerkverbindingen vrij voor kritieke bronnen en verbetert je Largest Contentful Paint (LCP). Het feit dat Lighthouse het niet langer markeert, betekent dat je er zelf op moet controleren. Gebruik Real User Monitoring of controleer je pagina's handmatig op afbeeldingen die laden zonder loading="lazy".

Een kleine opfrisser: wat is lazy loading?

Lazy loading betekent dat afbeeldingen die niet in het zichtbare deel van de pagina staan op een later moment worden geladen, meestal vlak voordat ze in beeld scrollen. De browser haalt de afbeelding pas op wanneer de gebruiker in de buurt komt. Dit bespaart bandbreedte en stelt de browser in staat om zich te focussen op de bronnen die er echt toe doen voor de initiële render.

Wat veroorzaakt eager loaded offscreen afbeeldingen?

Afbeeldingen worden standaard niet uitgesteld. Offscreen afbeeldingen die niet worden uitgesteld belanden op de pagina omdat het loading attribuut ontbreekt of omdat de afbeelding niet wordt afgehandeld door een lazy loading library. Veelvoorkomende oorzaken:

• Slecht gecodeerde plugins in je CMS.
• Plugins die native lazy loading uitschakelen.
• Achtergrondafbeeldingen (deze vereisen een andere aanpak dan loading="lazy").
• Page builders die slechte HTML genereren (bijvoorbeeld: Elementor of WP Bakery).
• Tekst die is gekopieerd en geplakt in een WYSIWYG-editor (zoals TinyMCE).
• Slecht gecodeerde templates.

Hoe beïnvloeden offscreen afbeeldingen je Core Web Vitals?

Offscreen afbeeldingen hebben geen directe impact op Lighthouse statistieken. Maar ze maken het renderen van een webpagina onnodig gecompliceerd. Je browser moet meer bronnen downloaden voordat de pagina op het scherm kan worden weergegeven. Er zijn 3 problemen met eager loaded offscreen afbeeldingen:

• Meer downloads voor het renderen. Je browser moet afbeeldingen downloaden die de gebruiker nog niet eens kan zien.
• Kritieke bronnen worden gedeprioriteerd. De afbeeldingen concurreren om bandbreedte met bronnen die daadwerkelijk nodig zijn voor de rendering, zoals je CSS en je LCP afbeelding.
• Hoger geheugengebruik. Het decoderen van afbeeldingen waar de gebruiker nog niet naartoe is gescrold verspilt geheugen, vooral op low-end mobiele apparaten.

Volgens het Page Weight hoofdstuk van de 2025 Web Almanac laadt de mediane mobiele pagina 15 afbeeldingen. Bij het 90e percentiel springt dat aantal naar 52. Op pagina's met veel afbeeldingen kan het lazy loaden van de offscreen afbeeldingen een wezenlijk verschil maken. Bij sites die worden gemonitord door CoreDash behaalt 76% van de pagina's die offscreen afbeeldingen correct lazy loaden de LCP, vergeleken met 59% van de pagina's die dat niet doen.

Hoe je 'defer offscreen images' oplost

Om eager loaded offscreen afbeeldingen op te lossen, voeg je loading="lazy" toe aan elke afbeelding die zich below-the-fold bevindt. Native lazy loading wordt nu ondersteund door 95% van de browsers wereldwijd, waaronder Chrome, Firefox, Safari en Edge. Je hebt hier geen library voor nodig.

<img loading="lazy"
     src="image.webp"
     alt="een native lazy loaded afbeelding"
     width="300" height="300">

Traceer de oorsprong van je eager loaded afbeeldingen. Controleer welke afbeeldingen laden zonder een loading attribuut en zoek uit wat ze op de pagina plaatst. Er zijn 5 gebruikelijke verdachten:

1. Slecht gecodeerde plugins in je CMS.
   Sommige plugins voegen direct HTML toe aan de pagina en gebruiken niet de juiste hooks die lazy loading mogelijk maken.
2. Plugins die native lazy loading uitschakelen.
   Sommige plugins schakelen native lazy loading standaard uit. Controleer je plugin-instellingen.
3. Page builders die slechte HTML genereren.
   Page builders zoals Elementor of WP Bakery creëren vaak logge code die verre van perfect is. Hier is geen makkelijke oplossing voor. De oplossing omvat het opschonen van je code en het veranderen van je workflow.
4. Tekst gekopieerd en geplakt in een WYSIWYG-editor.
   De meeste WYSIWYG-editors zoals TinyMCE doen slecht werk met het opschonen van geplakte code, vooral wanneer dit geplakt is vanuit een andere rich text bron zoals Microsoft Word. Deze editors voegen mogelijk geen lazy loading toe aan je afbeeldingen.
5. Slecht gecodeerde templates.
   Zelfs wanneer lazy loading is ingeschakeld, worden hardcoded afbeeldingen in je templates mogelijk nog steeds niet lazy loaded. Controleer je templates op offscreen afbeeldingen en voorzie ze van lazy loading.

Lazy load je LCP afbeelding niet

Dit is de belangrijkste regel van lazy loading: pas nooit loading="lazy" toe op je Largest Contentful Paint afbeelding. De LCP afbeelding is bijna altijd de hero afbeelding of het grootste zichtbare element in de viewport. Volgens de 2025 Web Almanac past 16% van de mobiele pagina's nog steeds lazy loading toe op hun LCP afbeelding. Dat ene attribuut kan 200 tot 500 milliseconden toevoegen aan je LCP.

Doe in plaats daarvan het tegenovergestelde voor je LCP afbeelding. Zorg ervoor dat deze zo snel mogelijk laadt met fetchpriority="high":

<img fetchpriority="high"
     loading="eager"
     src="hero.webp"
     alt="Hero afbeelding"
     width="1200" height="600">

Als je per ongeluk je LCP afbeelding lazy loaded hebt, lees dan hoe je een lazily loaded LCP afbeelding oplost. Voor een complete gids over het optimaliseren van afbeeldingen, zie afbeeldingen optimaliseren voor Core Web Vitals.

Cheatsheet voor het laden van afbeeldingen

Niet elke afbeelding moet op dezelfde manier worden behandeld. Hier is hoe je omgaat met de 4 meest voorkomende scenario's:

Native lazy loading vs lazy loading scripts

Gebruik native loading="lazy". In 2026 is er geen reden om een JavaScript lazy loading library toe te voegen voor standaard <img> elementen. Native lazy loading wordt ondersteund door alle grote browsers, inclusief Safari (sinds versie 15.4), en dekt 95% van de gebruikers wereldwijd. Het vereist geen JavaScript, voegt geen overhead toe en werkt out of the box.

Libraries zoals lazysizes waren essentieel voordat browsers native lazy loading ondersteunden. Ze worden niet langer onderhouden en zijn voor de meeste sites niet meer nodig. De enige scenario's waarin je nog steeds een JavaScript-oplossing nodig zou kunnen hebben:

• CSS achtergrondafbeeldingen. Native lazy loading werkt alleen op <img> en <iframe> elementen. Voor achtergrondafbeeldingen heb je IntersectionObserver of content-visibility: auto nodig.
• Aangepaste laaddrempels. Chrome begint met het laden van "lazy" afbeeldingen ruwweg 1250px onder de viewport op snelle verbindingen en 2500px op trage verbindingen. Je kunt deze afstand niet aanpassen. Als je meer controle nodig hebt, geeft een IntersectionObserver met een aangepaste rootMargin je dat.

Mocht je toch een library nodig hebben, gebruik dan vanilla-lazyload in plaats van lazysizes. Deze wordt actief onderhouden, gebruikt IntersectionObserver en ondersteunt achtergrondafbeeldingen.

Voorkom layout shift bij lazy loaded afbeeldingen

Neem altijd width en height attributen op bij lazy loaded afbeeldingen. Zonder expliciete dimensies weet de browser niet hoeveel ruimte hij moet reserveren. Wanneer de afbeelding eindelijk laadt, drukt deze de omringende content naar beneden, wat Cumulative Layout Shift (CLS) veroorzaakt. Volgens de 2025 Web Almanac heeft 62% van de mobiele pagina's nog steeds minstens één afbeelding zonder dimensies.

<!-- Fout: veroorzaakt layout shift -->
<img loading="lazy" src="photo.webp" alt="Foto">

<!-- Goed: dimensies reserveren ruimte -->
<img loading="lazy" src="photo.webp" alt="Foto" width="800" height="600">

Workarounds wanneer je niet kunt lazy loaden

Soms is het niet mogelijk om offscreen afbeeldingen uit te stellen. Je hebt misschien geen toegang tot de template of je CMS ondersteunt lazy loading niet. Er zijn een paar workarounds om de impact te verminderen. Deze zijn verre van perfect en kunnen nieuwe uitdagingen introduceren.

• Comprimeer je afbeeldingen. Kleinere afbeeldingen hebben minder impact op de laadprestaties dan grote afbeeldingen. Gebruik moderne compressietechnieken om de bestandsgrootte te verkleinen.
• Gebruik snellere afbeeldingsformaten. Schakel over van PNG en JPEG naar WebP of AVIF. WebP comprimeert tot ongeveer 1.3 bits per pixel vergeleken met 2.0 voor JPEG, volgens het Media hoofdstuk van de 2024 Web Almanac.
• Splits grote pagina's op in meerdere pagina's. Het opsplitsen van grote pagina's vermindert het aantal afbeeldingen dat tegelijkertijd moet laden.
• Implementeer infinite scroll. Infinite scroll is in feite lazy loading, alleen niet voor afbeeldingen maar voor hele delen van de webpagina. Voor pagina's met veel herhalende elementen (denk aan Pinterest) kan infinite scroll de initiële laadtijd aanzienlijk versnellen.

Voor mobiel-specifieke overwegingen zijn offscreen afbeeldingen een nog groter probleem, omdat mobiele verbindingen trager zijn en mobiele viewports kleiner, wat betekent dat meer afbeeldingen offscreen belanden.

Welke aanpak je ook kiest, verifieer of het werkt bij echte gebruikers. Stel Real User Monitoring in om te volgen of je wijzigingen daadwerkelijk LCP en de algehele Core Web Vitals in de praktijk verbeteren.