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 geladen 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 geladen wordt en eindigt onder 3 keer de hoogte van het zichtbare deel van de pagina, en begint onder het zichtbare deel van de pagina.
• De afbeelding is groter dan 0,02 MB of laadt langer dan 50ms.
  Afbeeldingen die klein of inline zijn worden genegeerd. Lazy loading scripts gebruiken vaak kleine placeholder afbeeldingen die onder deze drempel vallen.
• De afbeelding heeft geen loading attribuut gedefinieerd.
  Lighthouse negeert afbeeldingen die het loading="lazy" of loading="eager" attribuut hebben.

Dit audit is verwijderd in Lighthouse 13

Vanaf Lighthouse 13 (oktober 2025) is dit audit volledig verwijderd. Het Chrome team concludeerde dat moderne browsers offscreen afbeeldingen al deprioriteren, waardoor het audit meer ruis dan nuttige feedback genereerde.

Maar het punt is: de optimalisatie zelf doet er nog steeds toe. Lazy loading van offscreen afbeeldingen vermindert bandbreedte, maakt netwerkverbindingen vrij voor kritieke resources en verbetert je Largest Contentful Paint (LCP). Het feit dat Lighthouse het niet meer 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".

Ter herinnering: wat is lazy loading?

Lazy loading betekent dat afbeeldingen die niet in het zichtbare deel van de pagina staan op een later tijdstip worden geladen, meestal net voordat ze in beeld scrollen. De browser haalt de afbeelding pas op wanneer de gebruiker er dichtbij komt. Dit bespaart bandbreedte en laat de browser zich concentreren op de resources die er echt toe doen voor de initiële render.

Wat veroorzaakt eager geladen offscreen afbeeldingen?

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

• Slecht geprogrammeerde plugins in je CMS.
• Plugins die native lazy loading uitschakelen.
• Achtergrondafbeeldingen (deze hebben een andere aanpak nodig dan loading="lazy").
• Page builders die slechte HTML genereren (bijvoorbeeld: Elementor of WP Bakery).
• Tekst die gekopieerd en geplakt wordt in een WYSIWYG editor (zoals TinyMCE).
• Slechte template programmering.

Hoe beïnvloeden offscreen afbeeldingen je Core Web Vitals?

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

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

Volgens het Page Weight hoofdstuk van de 2025 Web Almanac laadt de gemiddelde mobiele pagina 15 afbeeldingen. Bij het 90e percentiel springt dat aantal naar 52. Op afbeeldingszware pagina's kan lazy loading van de offscreen afbeeldingen een echt verschil maken. Over sites die worden gemonitord door CoreDash slaagt [CD:placeholder]% van de pagina's die offscreen afbeeldingen correct lazy loaden voor LCP, vergeleken met [CD:placeholder]% van de pagina's die dat niet doen.

Hoe los je 'defer offscreen images' op

Om eager geladen offscreen afbeeldingen op te lossen, voeg loading="lazy" toe aan elke afbeelding die onder de vouw staat. Native lazy loading wordt nu ondersteund door 95% van de browsers wereldwijd, inclusief Chrome, Firefox, Safari en Edge. Je hebt hier geen bibliotheek voor nodig.

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

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

1. Slecht geprogrammeerde plugins in je CMS.
   Sommige plugins voegen HTML direct 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 maken vaak opgeblazen code die verre van perfect is. Hier is geen eenvoudige oplossing voor. De oplossing omvat het opschonen van je code en het aanpassen van je workflow.
4. Tekst gekopieerd en geplakt in een WYSIWYG editor.
   De meeste WYSIWYG editors zoals TinyMCE doen slecht werk bij het opschonen van geplakte code, vooral wanneer geplakt vanuit een andere rich text bron zoals Microsoft Word. Deze editors voegen mogelijk geen lazy loading toe aan je afbeeldingen.
5. Slechte template programmering.
   Zelfs wanneer lazy loading is ingeschakeld, worden hardcoded afbeeldingen in je templates mogelijk nog steeds niet lazy geladen. Controleer je templates op offscreen afbeeldingen en lazy load ze.

Lazy load niet je LCP afbeelding

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 aan je LCP toevoegen.

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

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

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

Afbeelding-laadcheatsheet

Niet elke afbeelding moet op dezelfde manier worden behandeld. Zo ga je om 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 bibliotheek toe te voegen voor standaard <img> elementen. Native lazy loading wordt ondersteund door alle grote browsers inclusief Safari (sinds versie 15.4), met een dekking van 95% van de gebruikers wereldwijd. Het vereist geen JavaScript, voegt geen overhead toe en werkt direct uit de doos.

Bibliotheken zoals lazysizes waren essentieel voordat browsers native lazy loading ondersteunden. Ze worden niet meer onderhouden en zijn niet meer nodig voor de meeste sites. De enige scenario's waar je mogelijk nog een JavaScript oplossing nodig hebt:

• 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 op ongeveer 1250px onder de viewport bij snelle verbindingen en 2500px bij langzame verbindingen. Je kunt deze afstand niet aanpassen. Als je meer controle nodig hebt, biedt een IntersectionObserver met een aangepaste rootMargin je dat.

Als je toch een bibliotheek nodig hebt, gebruik dan vanilla-lazyload in plaats van lazysizes. Het wordt actief onderhouden, gebruikt IntersectionObserver en ondersteunt achtergrondafbeeldingen.

Voorkom layout shift bij lazy geladen afbeeldingen

Voeg altijd width en height attributen toe aan lazy geladen afbeeldingen. Zonder expliciete afmetingen weet de browser niet hoeveel ruimte er gereserveerd moet worden. Wanneer de afbeelding uiteindelijk laadt, duwt het 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 afmetingen.

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

<!-- Goed: afmetingen reserveren ruimte -->
<img loading="lazy" src="photo.webp" alt="Photo" 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 het template of je CMS ondersteunt geen lazy loading. 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 tegelijk geladen moet worden.
• Implementeer infinite scroll. Infinite scroll is eigenlijk lazy loading, maar dan niet voor afbeeldingen maar voor hele delen van de webpagina. Voor pagina's met veel herhaalde 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 langzamer zijn en mobiele viewports kleiner, wat betekent dat meer afbeeldingen offscreen terechtkomen.

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