Optimaliseer afbeeldingen voor Core Web Vitals

Hoe afbeeldingen de Core Web Vitals beïnvloeden

Afbeeldingen zijn verantwoordelijk voor de Largest Contentful Paint op 85% van de desktop pagina's en 76% van de mobiele pagina's, volgens de 2025 Web Almanac. Dat maakt afbeeldingsoptimalisatie de meest impactvolle actie die je kunt ondernemen voor jouw Core Web Vitals. Maar afbeeldingen beïnvloeden niet alleen de laadsnelheid. Ze kunnen layout shifts veroorzaken en, op pagina's met veel afbeeldingen, zelfs de interactiviteit vertragen. Deze gids behandelt elke invalshoek: van HTML-attributen en preloading tot responsieve afbeeldingen, moderne formaten en de strategieën die je op elke afbeelding op je pagina zou moeten toepassen.

Laatst beoordeeld door Arjen Karel in februari 2026

Welke Core Web Vitals kunnen door afbeeldingen worden beïnvloed?

Je zult misschien verbaasd zijn om te horen dat afbeeldingen alle Core Web Vitals kunnen beïnvloeden. Afbeeldingen die laat in het renderproces in de wachtrij worden geplaatst voor download, of simpelweg te groot zijn, resulteren meestal in een slechte LCP score. Als de afmetingen van afbeeldingen niet zijn ingesteld of veranderen tijdens de laadfase, kunnen afbeeldingen ook de CLS score beïnvloeden. En tot slot, als het decoderen van afbeeldingen te veel werk op de main thread in beslag neemt, kunnen ze zelfs de INP beïnvloeden. Laten we dit van dichterbij bekijken:

Largest Contentful Paint

Largest Contentful Paint (LCP) meet hoe lang het duurt voordat het grootste element op de pagina (zoals een afbeelding of video) zichtbaar wordt voor de gebruiker. Volgens de 2025 Web Almanac zijn afbeeldingen het LCP element op 85% van de desktop pagina's en 76% van de mobiele pagina's. Als een afbeelding te laat in de wachtrij wordt geplaatst of er te lang over doet om te laden, kan dit de LCP score van de pagina aanzienlijk vertragen.

Cumulative Layout Shift

Cumulative Layout Shift (CLS) meet hoeveel de content op een pagina verschuift tijdens het laden. Afbeeldingen kunnen layout shifts veroorzaken als ze niet de juiste afmetingen hebben of als ze op de pagina worden ingevoegd nadat deze al is geladen, waardoor andere elementen gaan verschuiven. De 2025 Web Almanac rapporteert dat 65% van de desktop pagina's nog steeds minimaal één afbeelding zonder expliciete afmetingen heeft.

Interaction to Next Paint (INP)

Afbeeldingen kunnen ook de Interaction to Next Paint (INP) beïnvloeden, wat de tijd meet die een pagina nodig heeft om visueel te reageren na een gebruikersinteractie. Als er te veel grote afbeeldingen zijn die gedecodeerd moeten worden, kan het langer duren voordat de pagina reageert op gebruikersinteracties, wat leidt tot een slechte INP score. Dit komt het meest voor op productoverzichtspagina's waar honderden afbeeldingen concurreren om resources.

Stap 1: Optimaliseer het HTML image element voor snelheid

Src attribuut

Specificeert de URL van de afbeelding. Deze eigenschap is essentieel, omdat het de browser vertelt waar de afbeelding te vinden is.

Width en height attribuut

Specificeert de breedte (width) en hoogte (height) van de afbeelding in pixels. Deze eigenschappen zijn belangrijk voor het correct renderen van de afbeelding op de pagina, omdat ze de grootte van de afbeeldingscontainer bepalen en hoe de afbeelding daarin past. Stel altijd zowel width als height in om layout shifts te voorkomen.

Alt attribuut

Specificeert alternatieve tekst voor de afbeelding als deze niet kan worden weergegeven. Dit is belangrijk voor toegankelijkheidsdoeleinden, omdat het visueel gehandicapte gebruikers helpt te begrijpen waar de afbeelding over gaat. Het is ook belangrijk voor zoekmachineoptimalisatie (SEO), aangezien zoekmachines de alt-tekst gebruiken om de content van de afbeelding te begrijpen.

Loading attribuut (lazy loading)

Specificeert hoe de browser de afbeelding moet laden (lazy, eager of auto). Deze eigenschap is belangrijk voor het verbeteren van de paginaprestaties, omdat het toestaat dat afbeeldingen asynchroon worden geladen en alleen wanneer ze nodig zijn. Stel nooit loading="lazy" in op de LCP afbeelding. Volgens de 2025 Web Almanac past 16% van de pagina's nog steeds lazy-loading toe op hun LCP afbeelding, wat een van de meest gemaakte prestatiefouten op het web is.

Srcset attribuut

Sizes attribuut

Decoding attribuut

Fetchpriority attribuut

Het fetchpriority attribuut specificeert de prioriteit van het ophalen van een resource ten opzichte van andere resources op de pagina. Het attribuut kan een van drie waarden hebben: "high", "low" of "auto". Een resource met een hoge prioriteit wordt geladen vóór resources met een lagere prioriteit. Vanaf 2026 wordt fetchpriority ondersteund in alle moderne browsers (Chrome 102+, Safari 17.2+, Firefox 132+, Edge 102+) en is het veilig te gebruiken in productie. Slechts 17% van de pagina's gebruikt het op hun LCP afbeelding, wat betekent dat de overgrote meerderheid van de websites een makkelijke winst laat liggen.

Stap 2: Zorg ervoor dat de afbeelding zo vroeg mogelijk in de wachtrij voor download staat

Het tweede wat je moet doen, nadat je de HTML hebt geoptimaliseerd, is kijken naar image scheduling. In veel gevallen is de grootste bottleneck als het gaat om afbeeldingen die de LCP metric beïnvloeden, een late scheduling. Als een browser de kans heeft om het LCP element vroeg tijdens het renderproces te downloaden, zal de afbeelding zo vroeg mogelijk beschikbaar zijn voor de browser en kan de browser dat element vroeg in het renderproces beginnen te painten.

Klinkt simpel toch? Maar hoe zorgen we ervoor dat de afbeelding zo vroeg mogelijk in de wachtrij komt om gedownload te worden?

Preload het LCP element

De meest effectieve manier om een vroege download te garanderen, is om de afbeelding te preloaden. Het preloaden van de afbeelding doe je met een simpele tag aan het begin van het <head> element. Bijvoorbeeld:

<link rel="preload" as="image" href="image.jpg">

Deze simpele tag vertelt de browser dat we "image.jpg" vrij snel nodig zullen hebben en de browser zal onmiddellijk beginnen met het downloaden van dit bestand.

Op sites die gemonitord worden door CoreDash, scoort 83% van de page loads met een gepreloade LCP afbeelding 'goed' op LCP, vergeleken met 65% zonder preloading.

Eager load het LCP element

Gebruik hoge fetchpriority

Als je om de een of andere reden het LCP element niet kunt preloaden, zorg er dan in ieder geval voor dat het element het fetchpriority attribuut ingesteld heeft op high. Dit zal de browser een hint geven dat een afbeelding belangrijk is voor de pagina en de browser zal deze met hoge prioriteit downloaden. Houd er rekening mee dat het gebruik van fetchpriority="high" meestal niet zo efficiënt is als het preloaden van een afbeelding!

Stap 3: Zorg ervoor dat de afbeelding zo snel mogelijk gedownload wordt

Het derde wat je moet doen, is ervoor zorgen dat je geen kostbare netwerkresources verspilt aan afbeeldingen die groter zijn dan ze zouden moeten zijn. Je kunt dit doen door responsieve afbeeldingen te gebruiken, door compressie te gebruiken en door nieuwe en snellere afbeeldingsformaten te gebruiken.

Responsieve afbeeldingen

Hier is een responsieve afbeelding met behulp van srcset en sizes:

<img
  src="hero-800.jpg"
  srcset="hero-400.jpg 400w, hero-800.jpg 800w, hero-1200.jpg 1200w"
  sizes="(max-width: 600px) 100vw, 800px"
  width="800" height="450" alt="Descriptive alt text">

De browser kiest de meest geschikte afbeelding op basis van de breedte van de viewport. Voor lazy-loaded below-the-fold afbeeldingen kun je ook sizes="auto" gebruiken (ondersteund in Chrome 126+ en Edge 126+), waardoor de browser automatisch het juiste formaat kan berekenen op basis van de CSS layout van de afbeelding.

Afbeeldingscompressie

Nieuwe en snellere afbeeldingsformaten

Afbeeldingen zijn vaak een van de grootste resources op een webpagina, en ze kunnen de laadsnelheid van een pagina aanzienlijk vertragen als ze niet zijn geoptimaliseerd. Moderne afbeeldingsformaten zoals WebP en AVIF bieden aanzienlijk betere compressie dan JPEG met behoud van dezelfde visuele kwaliteit.

WebP wordt ondersteund door vrijwel alle browsers (~99% wereldwijde ondersteuning) en verkleint de bestandsgrootte doorgaans met 25-35% in vergelijking met JPEG. AVIF gaat nog verder met 50%+ besparing ten opzichte van JPEG en heeft nu 94,7% browser ondersteuning (Chrome 85+, Firefox 93+, Safari 16.4+). Desondanks laat de 2025 Web Almanac zien dat AVIF slechts voor 0,7% van de LCP afbeeldingen wordt gebruikt, terwijl JPEG met 57% nog steeds domineert. Dat is een enorme kans.

Gebruik het <picture> element om het beste formaat te serveren dat door elke browser wordt ondersteund:

<picture>
  <source srcset="hero.avif" type="image/avif">
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" width="800" height="450" alt="Descriptive alt text">
</picture>

De browser zal eerst AVIF proberen, terugvallen op WebP en JPEG als laatste redmiddel gebruiken. Als je nieuwsgierig bent naar de toekomst, lees dan over JPEG XL en de huidige status van browser ondersteuning.

Stap 4: Elimineer layout shift!

Afbeeldingen die tijdens het laden van formaat veranderen, veroorzaken een layout shift. Zo simpel is het. Deze sectie behandelt de 3 meest voorkomende redenen. Voor de complete gids voor alle afbeeldings- en media CLS-oorzaken (inclusief video's, iframes, art direction, responsive image mismatches en lazy loading), zie Hoe afbeeldingen en media layout shift veroorzaken.

1. Ontbrekende afbeeldingsdimensies

2. Styling problemen

Meestal wordt voorkomen dat afbeeldingen groter worden dan de viewport door een simpele CSS truc:

img{
   max-width:100%;
   height:auto;
}

Dit is een geweldige truc en je zou deze moeten gebruiken. Helaas zie ik regelmatig varianten van deze truc die wél een layout shift veroorzaken. Bijvoorbeeld door width:auto toe te voegen:

img{
   max-width:100%;
   height:auto;
   width:auto;
}

Dit zorgt ervoor dat elke afbeelding rendert met een auto width en height. Dit betekent meestal dat de browser de afbeelding op 0x0px zal renderen voordat de afbeelding gedownload is.

3. Placeholders

Sommige JavaScript-gebaseerde lazy loading scripts gebruiken placeholders. Als je een soort CSS truc gebruikt zoals de hierboven genoemde max-width:100% en height:auto, dan komt de auto height van de vierkante placeholder niet overeen met het height attribuut van de afbeelding. In principe zal de afbeelding eerst renderen met de vierkante placeholder op 720x720 en wanneer de uiteindelijke afbeelding is gedownload, zal deze op 720x180 renderen:

<img
  src="1x1placeholder.png"
  data-src="hero.png"
  width="720"
  height="180"
  style="height:auto;max-width:100%"
>

Stap 5: Bescherm de main thread

Het volgende waar je voor moet zorgen is dat er niet te veel afbeeldingen tegelijkertijd op de main thread gedecodeerd worden. Meestal is dit geen probleem, maar ik heb het vaak zien gebeuren op productoverzichtspagina's (waar soms wel 500 afbeeldingen om resources concurreren!).

De truc is om decoding="async" toe te voegen aan alle afbeeldingen om ervoor te zorgen dat deze afbeeldingen op een afzonderlijke thread kunnen worden gedecodeerd. Probeer ook te voorkomen dat er zoveel afbeeldingen tegelijk gedecodeerd worden door loading="lazy" toe te voegen aan alle below-the-fold en verborgen afbeeldingen.

Stap 6: Kies de juiste strategie voor elke afbeelding!

Afbeeldingsstrategieën voor het LCP element

Het LCP element is meestal het belangrijkste visuele element. We moeten deze dus echt prioriteit geven.

1. Preload de afbeelding vroeg in de head van de pagina met deze code: <link rel="preload" as="image" href="path-to-img.png">
2. Vertel de browser dat deze afbeelding niet lazy loaded mag zijn door loading="eager" in te stellen of door het loading attribuut weg te laten
3. Geef een hint aan de browser dat deze afbeelding met een hoge prioriteit gedownload moet worden door fetchpriority="high" te gebruiken (als je de afbeelding al preload, kun je dit deel overslaan)
4. Stel decoding="sync" in aangezien dit element zo belangrijk is dat we het op de main thread willen decoderen

Hier is een compleet voorbeeld van een geoptimaliseerde, responsieve LCP afbeelding met preloading:

<!-- In <head> -->
<link rel="preload" as="image" href="hero-800.jpg"
  imagesrcset="hero-400.jpg 400w, hero-800.jpg 800w, hero-1200.jpg 1200w"
  imagesizes="(max-width: 600px) 100vw, 800px">

<!-- In <body> -->
<img src="hero-800.jpg"
  srcset="hero-400.jpg 400w, hero-800.jpg 800w, hero-1200.jpg 1200w"
  sizes="(max-width: 600px) 100vw, 800px"
  width="800" height="450" alt="Descriptive alt text"
  fetchpriority="high" decoding="sync">

Afbeeldingsstrategie voor logo's en andere zichtbare (non-LCP) afbeeldingen

Zichtbare afbeeldingen moeten vrij snel tijdens het laden van de pagina worden ingeladen, maar bij voorkeur ná het LCP element. We kunnen dit bereiken door het LCP element te preloaden. Dat geeft deze zichtbare afbeeldingen hun natuurlijke, correcte downloadvolgorde.

1. Vertel de browser dat deze afbeelding niet lazy loaded mag zijn door loading="eager" in te stellen of door het loading attribuut weg te laten
2. Stel decoding="async" in, aangezien dit element veilig buiten de main thread om gedecodeerd kan worden!

Afbeeldingsstrategie voor below-the-fold afbeeldingen

Alle below-the-fold afbeeldingen moeten lazy loaded zijn. Zo simpel is het! Er zijn geen uitzonderingen!

1. Vertel de browser dat deze afbeelding lazy loaded moet zijn door loading="lazy" in te stellen
2. Stel decoding="async" in, aangezien dit element veilig buiten de main thread om gedecodeerd kan worden!

Vermijd achtergrondafbeeldingen

Als je achtergrondafbeeldingen gebruikt, moet je dit heroverwegen. Achtergrondafbeeldingen kunnen niet lazy loaded zijn, je kunt de decoding eigenschap niet sturen en je kunt de fetchpriority niet instellen. Achtergrondafbeeldingen zijn meestal niet responsief, wat je waarschijnlijk veel bandbreedte zal kosten. Maar nog belangrijker: achtergrondafbeeldingen worden meestal ontdekt nadat de browser de CSS bestanden heeft gedownload. Dit is vrijwel nooit het juiste moment om een afbeeldingsdownload te triggeren! Lees waarom achtergrondafbeeldingen slecht zijn en hoe je achtergrondafbeeldingen kunt uitstellen als je geen keuze hebt.

Je kunt normale image tags gebruiken in combinatie met de CSS object-fit:cover om normale afbeeldingen zich als achtergrondafbeeldingen te laten gedragen!

Monitor de impact met Real User Monitoring

Nadat je deze optimalisaties hebt toegepast, verifieer of ze daadwerkelijk de prestaties voor echte gebruikers verbeteren. Lab tools zoals Lighthouse kunnen bevestigen dat je wijzigingen correct zijn, maar alleen Real User Monitoring toont je de daadwerkelijke impact op je bezoekers. Volg je LCP, CLS en INP in de loop van de tijd om te bevestigen dat je afbeeldingsoptimalisaties werken zoals verwacht.