Afbeeldingen optimaliseren voor Core Web Vitals

Hoe afbeeldingen de Core Web Vitals beïnvloeden

Afbeeldingen zijn verantwoordelijk voor de Largest Contentful Paint op 85% van de desktoppagina's en 76% van de mobiele pagina's, volgens de 2025 Web Almanac. Dat maakt beeldoptimalisatie het meest impactvolle dat je kunt doen voor je 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 elk aspect: van HTML-attributen en preloading tot responsieve afbeeldingen, moderne formaten en de strategieën die je op elke afbeelding op je pagina moet toepassen.

Laatst beoordeeld door Arjen Karel in februari 2026

Welke Core Web Vitals kunnen afbeeldingen beïnvloeden?

Het zal je misschien verbazen dat afbeeldingen alle Core Web Vitals kunnen beïnvloeden. Afbeeldingen die pas laat tijdens het renderen in de wachtrij voor downloaden worden geplaatst, of die simpelweg te groot zijn, resulteren meestal in een hoge LCP-score. Als afbeeldingsdimensies 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 main thread-werk in beslag neemt, kunnen ze zelfs de INP beïnvloeden. Laten we dit nader 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 desktoppagina's en 76% van de mobiele pagina's. Als een afbeelding te laat in de wachtrij wordt geplaatst of te lang duurt 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 correct gedimensioneerd zijn of als ze op de pagina worden ingevoegd nadat deze al is geladen, waardoor andere elementen verspringen. De 2025 Web Almanac meldt dat 65% van de desktoppagina's nog steeds minstens één afbeelding heeft zonder expliciete dimensies.

Interaction to Next Paint (INP)

Afbeeldingen kunnen ook Interaction to Next Paint (INP) beïnvloeden, dat meet hoe lang het duurt voordat een pagina visueel reageert nadat een gebruiker ermee interacteert. Als er te veel grote afbeeldingen zijn die gedecodeerd moeten worden, kan de pagina langer nodig hebben om te reageren op gebruikersinteracties, wat leidt tot een slechte INP-score. Dit komt het meest voor op productoverzichtspagina's waar honderden afbeeldingen om resources concurreren.

Stap 1: Optimaliseer het HTML image-element voor snelheid

Src-attribuut

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

Width- en height-attribuut

Specificeert de breedte en hoogte van de afbeelding in pixels. Deze attributen zijn belangrijk voor het correct renderen van de afbeelding op de pagina, omdat ze de grootte van de afbeeldingscontainer definiëren en hoe de afbeelding erin past. Stel altijd zowel width als height in om layout shifts te voorkomen.

Alt-attribuut

Specificeert alternatieve tekst voor de afbeelding als deze niet weergegeven kan worden. Dit is belangrijk voor toegankelijkheid, omdat het visueel beperkte gebruikers helpt te begrijpen waar de afbeelding over gaat. Het is ook belangrijk voor SEO, omdat zoekmachines de alt-tekst gebruiken om de inhoud van de afbeelding te begrijpen.

Loading-attribuut (lazy loading)

Specificeert hoe de browser de afbeelding moet laden (lazy, eager of auto). Dit attribuut is belangrijk voor het verbeteren van de paginaprestaties, omdat afbeeldingen hierdoor asynchroon en alleen wanneer nodig geladen kunnen worden. Stel nooit loading="lazy" in op de LCP-afbeelding. Volgens de 2025 Web Almanac lazy-loaden 16% van de pagina's nog steeds hun LCP-afbeelding, wat een van de meest voorkomende 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 lagere prioriteiten. Sinds 2026 wordt fetchpriority ondersteund in alle moderne browsers (Chrome 102+, Safari 17.2+, Firefox 132+, Edge 102+) en is het veilig om in productie te gebruiken. Slechts 17% van de pagina's gebruikt het op hun LCP-afbeelding, wat betekent dat de overgrote meerderheid van sites een makkelijke winst laat liggen.

Stap 2: Zorg ervoor dat de afbeelding zo vroeg mogelijk in de downloadwachtrij wordt geplaatst

Het tweede wat je moet doen, nadat je de HTML hebt geoptimaliseerd, is kijken naar de beeldplanning. In veel gevallen is het grootste knelpunt als het gaat om afbeeldingen die de LCP-metric beïnvloeden het te laat plannen. Als een browser de kans heeft om het LCP-element vroeg tijdens het renderproces te downloaden, is de afbeelding zo vroeg mogelijk beschikbaar voor de browser en kan de browser dat element vroeg in het renderproces gaan schilderen.

Klinkt simpel toch? Maar hoe zorgen we ervoor dat de afbeelding zo vroeg mogelijk in de downloadwachtrij wordt geplaatst?

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 wordt gedaan met een eenvoudige tag aan het begin van het <head>-element. Bijvoorbeeld:

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

Deze eenvoudige tag vertelt de browser dat we "image.jpg" binnenkort nodig hebben en de browser zal dit bestand onmiddellijk beginnen te downloaden.

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

Eager load het LCP-element

Gebruik hoge fetchpriority

Als je om wat voor reden dan ook het LCP-element niet kunt preloaden, zorg er dan op zijn minst voor dat het element het fetchpriority-attribuut op high heeft staan. Dit geeft de browser een hint 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 wordt gedownload

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 met responsieve afbeeldingen, compressie en nieuwe, snellere beeldformaten.

Responsieve afbeeldingen

Hier is een responsieve afbeelding met 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 viewport-breedte. Voor lazy-loaded below-the-fold afbeeldingen kun je ook sizes="auto" gebruiken (ondersteund in Chrome 126+ en Edge 126+), waarmee de browser automatisch de juiste grootte berekent op basis van de CSS-layout van de afbeelding.

Beeldcompressie

Nieuwe en snellere beeldformaten

Afbeeldingen zijn vaak een van de grootste resources op een webpagina en ze kunnen de laadsnelheid van een pagina aanzienlijk vertragen als ze niet geoptimaliseerd zijn. Moderne beeldformaten 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% vergeleken met JPEG. AVIF gaat nog verder met 50%+ besparing ten opzichte van JPEG en heeft nu 94,7% browserondersteuning (Chrome 85+, Firefox 93+, Safari 16.4+). Desondanks toont de 2025 Web Almanac dat AVIF slechts voor 0,7% van de LCP-afbeeldingen wordt gebruikt, terwijl JPEG nog steeds domineert met 57%. Dat is een enorme kans.

Gebruik het <picture>-element om het beste formaat te serveren dat elke browser ondersteunt:

<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 probeert eerst AVIF, valt terug op WebP en gebruikt JPEG als laatste optie. Als je benieuwd bent naar de toekomst, lees dan over JPEG XL en de huidige status van browserondersteuning.

Stap 4: Elimineer layout shift!

Afbeeldingen die van grootte veranderen terwijl ze laden veroorzaken een layout shift. Zo simpel is het. Er zijn 3 hoofdredenen waarom afbeeldingen een layout shift veroorzaken (er zijn er meer, maar deze 3 zijn de meest voorkomende):

1. Ontbrekende afbeeldingsdimensies

2. Stylingproblemen

Meestal worden afbeeldingen verhinderd om groter te worden dan de viewport met een eenvoudige CSS-truc:

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

Dit is een geweldige truc en je zou hem 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 automatische breedte en hoogte. Dit betekent meestal dat de browser de afbeelding op 0x0px rendert voordat de afbeelding is gedownload.

3. Placeholders

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

<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 niet te veel afbeeldingen tegelijkertijd op de main thread worden gedecodeerd. 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" aan alle afbeeldingen toe te voegen, zodat deze afbeeldingen op een aparte thread gedecodeerd kunnen worden. Probeer ook te voorkomen dat 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!

Beeldstrategie voor het LCP-element

Het LCP-element is meestal het belangrijkste visuele element. Dus we moeten dit echt prioriteren.

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 geladen moet worden door loading="eager" in te stellen of door het loading-attribuut weg te laten
3. Geef de browser een hint dat deze afbeelding met hoge prioriteit gedownload moet worden door fetchpriority="high" te gebruiken (als je de afbeelding preloadt, kun je dit deel overslaan)
4. Stel decoding="sync" in omdat 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">

Beeldstrategie voor logo's en andere zichtbare (niet-LCP) afbeeldingen

Zichtbare afbeeldingen moeten vrij snel tijdens het laden van de pagina geladen worden, maar bij voorkeur na 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 geladen moet worden door loading="eager" in te stellen of door het loading-attribuut weg te laten
2. Stel decoding="async" in omdat dit element veilig buiten de main thread gedecodeerd kan worden!

Beeldstrategie voor below-the-fold afbeeldingen

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

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

Vermijd achtergrondafbeeldingen

Als je achtergrondafbeeldingen gebruikt, moet je dit heroverwegen. Achtergrondafbeeldingen kunnen niet lazy geladen worden en je kunt het decoding-attribuut niet instellen en je kunt de fetchpriority niet instellen. Achtergrondafbeeldingen zijn meestal niet responsief, wat je waarschijnlijk veel bandbreedte kost. Maar het belangrijkste is dat achtergrondafbeeldingen meestal pas worden ontdekt nadat de browser de CSS-bestanden heeft gedownload. Dit is bijna nooit het juiste moment om een afbeeldingsdownload te starten! Lees waarom achtergrondafbeeldingen slecht zijn en hoe je achtergrondafbeeldingen kunt uitstellen wanneer 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

Na het toepassen van deze optimalisaties is het belangrijk om te verifiëren dat ze daadwerkelijk de prestaties voor echte gebruikers verbeteren. Labtools zoals Lighthouse kunnen bevestigen dat je wijzigingen correct zijn, maar alleen Real User Monitoring laat je de werkelijke impact op je bezoekers zien. Volg je LCP, CLS en INP over tijd om te bevestigen dat je beeldoptimalisaties werken zoals verwacht.