Langzame hero images repareren & Core Web Vitals

Langzame hero images repareren: in het kort

Hero images zijn grote afbeeldingen bovenaan een webpagina. Die hero images veroorzaken een lange Largest Contentful Paint wanneer ze niet geoptimaliseerd zijn. 9 van de 10 sites die ik moet optimaliseren hebben problemen met de hero images. In dit artikel laat ik je verschillende technieken zien om hero images te versnellen.

Laatst beoordeeld door Arjen Karel in februari 2026

Wat is een hero image?

Een Hero Image, soms een 'hero header' genoemd, is een grote afbeelding met tekst, vaak bovenaan een webpagina geplaatst. Een hero image dient als de eerste indruk van je bedrijf en aanbod vanwege de prominente plaatsing bovenaan een webpagina die meestal over de volledige breedte loopt.

Een korte herinnering: Hero images, de Core Web Vitals en de Largest Contentful Paint: 
Vanwege de grootte van de hero image (deze beslaat meestal de volledige breedte van de pagina en een groot deel van de hoogte van de zichtbare viewport) zal dit element in vrijwel alle gevallen het Largest Contentful Paint element worden.
De Largest Contentful Paint is een belangrijke Core Web Vitals metric. Het largest contentful paint element is het grootste element dat wordt weergegeven in de zichtbare viewport van de browser. Volgens de 2025 Web Almanac is op 76% van de mobiele pagina's het LCP element een afbeelding. Slechts 62% van de mobiele origins slaagt momenteel voor LCP. Repareer de hero image en je repareert LCP voor de meeste sites.
Omdat niet-geoptimaliseerde afbeeldingen veel bandbreedte verbruiken en daardoor lang duren om te laden, veroorzaken hero images vaak slechte Largest Contentful Paint metrics.

De hero image en de Largest Contentful Paint optimaliseren

Er zijn veel technieken om de hero images en de Largest Contentful Paint te optimaliseren. Ik zal ze hier uitleggen. De meeste technieken kunnen gecombineerd worden voor nog betere resultaten!

1. Preload de hero image of stuur 103 Early Hints

Wanneer je wilt dat een element zo snel mogelijk beschikbaar is in de browser, kun je dat element preloaden. Preloading maakt gebruik van resource hints. Resource hints vertellen de browser iets over de prioriteit van een element en triggeren een zeer vroege download van die resource. Volgens de 2025 Web Almanac preloadt slechts 2,1% van de pagina's hun LCP afbeelding. Dat is een enorme gemiste kans.

<link
  rel="preload"
  as="image"
  href="wolf.jpg"
  fetchpriority="high"
  imagesrcset="hero_400px.jpg 400w, hero.jpg 800w, hero_1600px.jpg 1600w"
  imagesizes="50vw">

103 Early Hints stellen servers in staat om resource hints te sturen voordat het definitieve HTML-antwoord er is. De browser kan beginnen met het preloaden van de hero image terwijl de server nog bezig is met het genereren van de pagina. Chrome, Edge en Firefox ondersteunen allemaal preloading via Early Hints. Safari ondersteunt preconnect maar nog geen preload via Early Hints. Lees voor meer informatie over het instellen hiervan de complete gids over 103 Early Hints.

Op sites die worden gemonitord door CoreDash hebben pagina's met een gepreloade LCP afbeelding een 'goed' LCP percentage van 81% vergeleken met 64% zonder preloading. Lees voor een volledig overzicht van alle preloading opties hoe je de LCP afbeelding preloadt.

2. Gebruik fetchpriority="high" op de hero image

Het fetchpriority attribuut vertelt de browser welke resources het belangrijkst zijn. Door fetchpriority="high" in te stellen op je hero image verhoog je de downloadprioriteit boven andere afbeeldingen en concurrerende resources zoals scripts en fonts.

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

Volgens de 2025 Web Almanac stelt slechts 17% van de pagina's fetchpriority="high" in op hun LCP afbeelding. Dat betekent dat 83% van de sites eenvoudige prestatiewinst laat liggen.

Je kunt ook fetchpriority="high" toevoegen aan de preload link hierboven. Gebruik fetchpriority="high" slechts op één afbeelding per pagina. Meerdere high-priority afbeeldingen concurreren met elkaar en heffen het voordeel op. Lees voor meer informatie over hoe browsers resources prioriteren de Core Web Vitals gids over resource prioritering.

3. Comprimeer de hero image en gebruik next-gen formaten

Het comprimeren van afbeeldingen maakt ze kleiner qua bestandsgrootte. Kleinere bestandsgroottes verbruiken minder bandbreedte en zijn sneller beschikbaar voor de browser. Afbeeldingen comprimeren kan in je foto-editor, in je CMS (tip: je developer kan het WordPress compressieniveau instellen) of met een online afbeeldingscompressie tool.

De meeste langzame hero images zijn langzamer dan nodig omdat ze worden aangeboden in het 'verkeerde' afbeeldingsformaat zoals PNG of JPEG. Er zijn veel snellere alternatieven voor JPEG en PNG zoals WebP en AVIF. Volgens de 2025 Web Almanac wordt 57% van de LCP afbeeldingen nog steeds als JPEG aangeboden en 26% als PNG, terwijl slechts 11% WebP gebruikt en minder dan 1% AVIF.

Voor veel CMS-systemen zijn er conversieplugins die je afbeeldingen naar next-gen formaten converteren. Wanneer afbeeldingsconversie moeilijk te integreren is in je website, kan een CDN met ondersteuning voor afbeeldingsconversie de oplossing zijn waar je naar zoekt. Lees voor een volledig overzicht van afbeeldingsoptimalisatie technieken afbeeldingen optimaliseren voor Core Web Vitals.

4. Gebruik geen background images, gebruik normale responsive images

Je hero image moet een normale afbeelding zijn en nooit een background image. De gebruikelijke manier om hero images te maken is door een background image toe te voegen aan de hero container en de background-size van die container op cover te zetten. Dit zorgt ervoor dat de hero image in alle gevallen op het scherm past.

Background images zijn slecht voor Core Web Vitals. Onthoud dat! Lees meer over waarom background images slecht zijn voor performance. Als je background images niet helemaal kunt vermijden, kun je op zijn minst background images uitstellen die zich onder de fold bevinden.

• Background images worden met een lagere prioriteit geladen
• Background images zijn niet responsive (tenzij je het echt ingewikkeld wilt maken)
• Background images kunnen Core Web Vitals problemen veroorzaken met de meeste lazy loading libraries

De manier waarop ik het doe is door een normale afbeelding in een absolute positie te plaatsen en de object-fit eigenschap van die afbeelding op cover te zetten. Zodra ik de background image heb veranderd naar een normale afbeelding kan ik responsive images gaan gebruiken. Als je Elementor gebruikt, bekijk dan hoe je Elementor hero images repareert.

Responsive images betekent dat voor verschillende apparaten (mobiel, desktop, tablet) een andere versie van dezelfde hero image kan worden gestuurd. Voor een desktop apparaat stuur ik misschien een enorme 1920x1280 hero image terwijl ik voor een mobiel apparaat slechts een kleinere 400x266 pixels hero image hoef te sturen. Dat is 25 keer minder data!

• De hero images worden nu met een hogere prioriteit geladen
• Ik kan nu responsive images gebruiken voor de hero image

style.css

<style>
#herocontainer{
    position:relative;
    padding:4rem 0
}
#heroimg{
    object-fit: cover;
    width: 100%;
    height: 100%;
    position: absolute;
    top: 0;
}
</style>

index.html

<div id="herocontainer">
<h1>Welcome to my site</h1>
<picture>
    <source
        type="image/webp"
        media="(max-width:540px)"
        srcset="herosm.webp">
    </source>
    <img fetchpriority="high" loading="eager" decoding="async" src="hero.webp" id="heroimg">
</picture>
</div>

5. Serveer hero images vanaf het hoofddomein en overweeg een CDN

Maar al te vaak zie ik dat de largest contentful paint afbeelding wordt geserveerd vanaf een ander domein, bijvoorbeeld 'static.mijndomein.nl'. Deze subdomeinen verwijzen vaak naar een CDN. Hoewel ik het gebruik van een CDN aanmoedig (zie hieronder) is een dergelijke opzet niet aan te raden. De afbeelding op het subdomein vereist een nieuwe verbinding met een nieuwe server. Nieuwe verbindingen zijn kostbaar en nemen waardevolle tijd in beslag. Wanneer de afbeelding wordt geserveerd vanaf het hoofddomein (bijvoorbeeld www.mijndomein.nl) kunnen de afbeeldingen veel sneller worden opgehaald via de reeds opgezette serververbinding.

Wanneer een CDN is ingesteld op het hoofddomein kan het een enorme snelheidsverbetering bieden. Vooral wanneer je site wordt bezocht vanuit de hele wereld. Een CDN heeft servers strategisch geplaatst over de hele wereld waar je statische resources (zoals afbeeldingen) worden gecachet voor snelle lokale responstijden. Dit betekent dat data niet over de hele wereld hoeft te reizen maar kan worden geserveerd vanaf een lokale edge server. Lees voor een complete installatiegids hoe je Cloudflare configureert voor Core Web Vitals.

6. Vermijd lazy loading op de hero image

Zorg ervoor dat er geen lazy loading wordt toegepast op je hero image. Hero images moeten altijd eager laden.

Veel sites, vooral WordPress sites, gebruiken een of andere WordPress pagespeed plugin zoals WP Rocket of WP Core Web Vitals. Deze plugins doen over het algemeen goed werk bij het versnellen van langzame sites maar ze kunnen dom niet repareren :-)

Deze plugins zullen afbeeldingen lazy loaden die goede kandidaten lijken om te lazy loaden. Als de hero image geen eager afbeelding is, zullen die plugins waarschijnlijk ook de hero image lazy loaden.

Dit zal in het beste geval een kleine vertraging in de LCP metrics veroorzaken. In het slechtste geval, vooral wanneer JavaScript-gebaseerde lazy loading is geactiveerd, zal het een grotere vertraging veroorzaken. Volgens de 2025 Web Almanac lazy-loadt ongeveer 17% van de pagina's hun LCP afbeelding. Dat is 17% van de sites die actief hun LCP verslechteren. Als Lighthouse je hiervoor waarschuwt, lees dan hoe je de waarschuwing voor lazy geladen LCP afbeeldingen oplost.

Afbeeldingen eager laden is simpel. Voeg gewoon loading="eager" toe aan de afbeelding. Merk op dat eager eigenlijk de standaardinstelling van de browser is. Het weglaten van het loading attribuut heeft hetzelfde effect. Het echte doel is ervoor zorgen dat de hero image NIET loading="lazy" heeft. Het expliciet toevoegen van eager is nog steeds nuttig als signaal van intentie, vooral op sites waar een CMS of plugin automatisch lazy loading toepast.

<img src="hero.webp" loading="eager" fetchpriority="high" width="800" height="400">

7. Vermijd layout shifts veroorzaakt door de hero image

Een ander veelvoorkomend probleem dat ik zie bij hero banners en hero images is dat ze een enorme layout shift veroorzaken. Deze layout shifts kunnen om verschillende redenen optreden.

• Het hero element wordt aangemaakt met JavaScript. Sommige hero plugins en page builders zoals Elementor staan erom bekend dat ze afhankelijk zijn van JavaScript om de hero content te renderen. Hoewel er niets mis is met JavaScript, zorg ervoor dat het hero element hetzelfde rendert zonder JavaScript.
• De fonts in het hero element veroorzaken een layout shift. Het hero element bevat meestal wat grote tekst met een call to action en een tagline. Zorg ervoor dat deze grote fonts geen layout shift veroorzaken.
• Ontbrekende afbeeldingsdimensies. Wanneer de hero image geen cover afbeelding is (hetzij als background image of als een absoluut gepositioneerde afbeelding) zullen ontbrekende afbeeldingsdimensies (breedte en hoogte) zeker een grote layout shift veroorzaken.

Hoewel het oplossen van de layout shift de Largest Contentful Paint niet verbetert, zal het wel de Core Web Vitals van de pagina verbeteren. Lees voor meer informatie over het oplossen van de layout shift de diepgaande gids over het oplossen van de Cumulative Layout Shift!

8. Gebruik 2-stage loading om de hero Core Web Vitals te verbeteren

2-stage loading is een snelle techniek die we toepassen op al onze afbeeldingen. We serveren eerst een afbeelding van extreem lage kwaliteit die naar verwachting veel eerder wordt gedownload dan de grotere afbeelding van hoge kwaliteit. Zodra de afbeelding van lage kwaliteit op het scherm is weergegeven, wordt de browser getriggerd om de afbeelding van hoge kwaliteit op de achtergrond op te halen. Zodra de afbeelding van hoge kwaliteit is gedownload, wordt de afbeelding van lage kwaliteit vervangen door de afbeelding van hoge kwaliteit.

Er zijn 3 methoden van 2-stage loading. De eerste twee zijn methoden die je zou moeten overwegen. De laatste is er een die je niet zou moeten doen.

1. Volledige 2-stage loading

Bij volledige 2-stage loading heeft de eerste afbeelding van lage kwaliteit exact dezelfde afmetingen (breedte en hoogte) als de originele afbeelding van hoge kwaliteit.

Het resultaat van deze 2-stage loading is dat het largest contentful paint element de veel snellere afbeelding van lage kwaliteit zal zijn (die vervolgens lazy wordt verwisseld). Het verwisselen van de afbeelding gaat allemaal zo snel dat een gewone bezoeker het waarschijnlijk nooit zal merken. Het resultaat van deze techniek is dat de LCP veel eerder wordt weergegeven, de pagina eerder 'klaar' lijkt, wat bijdraagt aan een veel betere user experience en verbeterde Core Web Vitals.

2. Kleinere inline placeholders

De kleinere placeholder is een behoorlijk coole techniek die één nadeel heeft: het verbetert de Core Web Vitals niet. Het is nog steeds een geweldige techniek omdat het de user experience verbetert.

Het basisidee is hetzelfde als bij de 2-stage loading techniek maar in plaats van één afbeelding van lage kwaliteit met dezelfde afmetingen wordt een veel kleinere afbeelding met kleinere afmetingen inline geplaatst via een data URI. De uiteindelijke hero image die het largest contentful paint element zal zijn wordt nog steeds op de achtergrond gedownload. Deze truc verbetert de Largest Contentful Paint niet maar laat de pagina nog sneller klaar lijken dan de 2-stage loading techniek.

3. Transparante placeholders

Een veelgebruikte 2-stage loading techniek en een methode om de browser te misleiden tot het sturen van een vroege Largest Contentful Paint metric is het gebruik van transparante SVG elementen. Die elementen zijn klein en kunnen inline worden geplaatst, net als de kleinere inline placeholder.

Het gebruik van een inline SVG element en het verwisselen ervan is eigenlijk een lazy loading techniek. Het voordeel van deze techniek is dat het cross-browser werkt. 

Lazy loading moet natuurlijk alleen worden toegepast op elementen buiten de viewport. In dit geval zal het transparante SVG element alleen de echte hero image vertragen en heeft het geen toegevoegde waarde voor je bezoeker. Waar de paint metrics misschien goed zijn, zal de UX van de pagina juist verslechteren.

Daarom moet de hero image altijd eager worden geladen zonder trucs die een slechte UX veroorzaken.

Alles samenvoegen

Zo ziet een geoptimaliseerde hero image eruit wanneer je preloading, fetchpriority, responsive images en eager loading combineert:

<!-- In de <head> -->
<link rel="preload" as="image" href="hero-800.webp" fetchpriority="high"
  imagesrcset="hero-400.webp 400w, hero-800.webp 800w, hero-1600.webp 1600w"
  imagesizes="100vw">

<!-- In de <body> -->
<img src="hero-800.webp"
  fetchpriority="high"
  loading="eager"
  decoding="async"
  srcset="hero-400.webp 400w, hero-800.webp 800w, hero-1600.webp 1600w"
  sizes="100vw"
  width="1600" height="900"
  alt="Beschrijvende alt tekst">

Verifieer na het aanbrengen van wijzigingen de verbetering met Real User Monitoring. Lighthouse geeft je een lab momentopname, maar Google rankt op basis van echte gebruikersdata die is verzameld over de afgelopen 28 dagen.