Achtergrondafbeeldingen zijn slecht
Waarom achtergrondafbeeldingen je Core Web Vitals schaden en hoe je ze kunt vervangen
Achtergrondafbeeldingen zijn slecht
Degenen die mij kennen of mij hebben horen spreken, hebben mij misschien wel eens horen praten over achtergrondafbeeldingen. Voor degenen die dat niet hebben: ik hou echt absoluut niet van achtergrondafbeeldingen. Hier is waarom ik niet van achtergrondafbeeldingen hou, hoe je snel pagina's met achtergrondafbeeldingen kunt vinden en hoe je ze kunt oplossen.
Laatst beoordeeld door Arjen Karel in maart 2026
Waarom achtergrondafbeeldingen slecht zijn voor de Core Web Vitals
Bij het laden van een webpagina heeft elk element zijn tijd en plaats. Met enkele moderne technieken zoals deferring, preloading, async loading, scheduling, het definiëren van de fetchpriority enzovoort, kunnen we alle kritieke bronnen behoorlijk goed onder controle krijgen. Behalve achtergrondafbeeldingen!
Kijk naar dit voorbeeld uit de praktijk:
Dagelijks, vooral op WordPress-sites, zie ik dit patroon. Alle normale afbeeldingen worden lazy loaded en sommige afbeeldingen (in dit geval de social media-iconen in de footer) zijn achtergrondafbeeldingen. Kun je raden wat er gebeurt?
<html>
<head>
<style>
footer {
/* een marge van 100 vh plaatst de footer buiten het scherm !*/
margin-top: 100vh;
>.social {
>.facebook {background-image: url('img/facebook.jpg');}
>.instagram {background-image: url('img/instagram.jpg');}
>.linkedin {background-image: url('img/linkedin.jpg');}
>.email {background-image: url('img/email.jpg');}
}
}
</style>
</head>
<body>
<!-- ja, deze afbeelding wordt lazy loaded, want een klein foutje is zo gemaakt! -->
<img loading="lazy" src="img/hero.jpg"></img>
<footer>
<div class="social">
<span class="facebook"></span>
<span class="instagram"></span>
<span class="linkedin"></span>
<span class="email"></span>
</div>
</footer>
</body>
</html>
Je raadt het misschien al: de achtergrondafbeeldingen buiten het scherm worden in de wachtrij gezet om te downloaden vóór de veel belangrijkere 'hero.jpg' afbeelding die meestal het Largest Contentful Paint-element op de pagina zal worden.
Maar dat is niet alles!
Zoals ik al zei, achtergrondafbeeldingen zijn slecht! Dat komt omdat, afgezien van de rare prioriteit die ze soms krijgen, achtergrondafbeeldingen de coole functies missen die normale afbeeldingen wel hebben!
- Geen lazy loading: er is geen loading-attribuut voor achtergrondafbeeldingen. Het
loading="lazy"attribuut dat werkt op<img>-tags (met 94,9% wereldwijde ondersteuning) bestaat simpelweg niet voor achtergronden. - Geen async decoding: er is geen decoding-attribuut voor achtergrondafbeeldingen
- Geen fetchpriority: er is geen fetchpriority-attribuut voor achtergrondafbeeldingen. Je kunt de browser niet vertellen welke achtergrondafbeelding het belangrijkst is. Bij
<img>-tags gebruikt volgens de 2025 Web Almanac al 17,3% van de mobiele pagina'sfetchpriority="high"op hun LCP-afbeelding. - Responsieve afbeeldingsbronnen: De image-set() functie voor achtergrondafbeeldingen heeft niet dezelfde functies die je krijgt met
srcseten het<picture>-element. - Geen width en height attribuut. Het niet kunnen instellen van het simpele width- en height-attribuut betekent dat de browser geen ruimte voor de afbeelding kan reserveren, wat Cumulative Layout Shift (CLS) veroorzaakt. Je eindigt met het gebruiken van CSS-workarounds, en meer code is altijd trager dan minder code met dezelfde complexiteit!
- Geen alt-tekst: achtergrondafbeeldingen hebben geen alt-attribuut, wat ten koste gaat van de toegankelijkheid en betekent dat Google Afbeeldingen ze niet kan indexeren.
Achtergrondafbeeldingen geladen via url() zijn geldige LCP-kandidaten. Een trage achtergrondafbeelding zal als je LCP verschijnen, maar je hebt geen van de bovenstaande tools om het te optimaliseren. De browser moet eerst de CSS downloaden en parsen voordat hij überhaupt weet dat de afbeelding bestaat. Deze resource load delay voegt volgens Google's eigen metingen ongeveer 400ms toe aan de mediane LCP.
Volgens de 2025 Web Almanac gebruikt 9% van de mobiele pagina's nog steeds een door CSS geïnitieerde afbeelding als hun LCP-element. Dat aantal is sinds 2022 niet veranderd. Op sites gemonitord door CoreDash, verbeterde het vervangen van een hero-achtergrondafbeelding door een <img>-tag de mediane LCP met 35%.
Snel alle achtergrondafbeeldingen op een pagina vinden
let bgimg = performance.getEntriesByType('resource')
.filter(rs => rs.initiatorType == 'css')
.map(rs => {
return {
name: rs.name,
initiator: rs.initiatorType
}
}) || [];
(bgimg.length > 0)?
console.table(bgimg):
console.log('Geen achtergrondafbeeldingen op deze pagina!');
Dit toont je een netjes opgemaakte tabel met alle namen van de achtergrondafbeeldingen en de initiators.
Hoe je achtergrondafbeeldingen kunt vermijden
Achtergrondafbeeldingen zijn makkelijk te vermijden. Hoe je dit doet, hangt af van de afbeelding zelf. Er zijn grofweg 2 methodes.
In het geval van 'normale afbeeldingen'
Je zou het niet geloven als ik het je vertelde, maar in de meeste gevallen waar ik achtergrondafbeeldingen vind, heeft het achtergrondgedeelte van de afbeelding niet eens een doel. De afbeeldingen moeten gewoon 'ergens op de pagina staan' en de background-image:url() wordt hiervoor misbruikt.
Als dit het geval is, voeg dan gewoon een normale image-tag toe en verwijder de achtergrondafbeelding uit de stylesheet.
In het geval van coverafbeeldingen:
Coverafbeeldingen zijn afbeeldingen die een parent container volledig bedekken. Het gebruik van achtergrondafbeeldingen als coverafbeeldingen is ergens wel logisch, omdat dit lang geleden de enige manier was om coverafbeeldingen te krijgen en ik vermoed dat mensen gewoon vasthouden aan wat ze kennen. Gelukkig zijn er betere opties voor ons beschikbaar. Laten we het dus oplossen!
In het geval van coverafbeeldingen verwijder je gewoon de style background-image: url(hero.jpg); background-size: cover; en plaats je een normale afbeelding in diezelfde container en pas je de CSS aan zodat deze er als volgt uitziet:
<style>
.img-container {
position: relative;
> img {
width: 100%;
height: 100%;
object-fit: cover;
position: absolute;
z-index: 1;
}
}
</style>
<div class="img-container">
<img
height="500"
width="300"
decoding="async"
loading="lazy"
src="hero.jpg"
srcset="hero-320w.jpg, hero-480w.jpg 1.5x"
alt="alt text"
fetchpriority="low"
>
</div>
Nu heb je een fatsoenlijke afbeelding met width, height, loading, decoding, srcset, fetchpriority en alt-attributen. Alles wat de browser nodig heeft om deze efficiënt te laden.
Wanneer je een achtergrondafbeelding moet behouden
Soms heb je wel een CSS-achtergrondafbeelding nodig: herhalende patronen, decoratieve overlays of gevallen waarin het CMS je geen andere optie geeft. In die situaties kun je de afbeelding preloaden zodat de browser deze vroeg ontdekt:
<link rel="preload" href="hero.webp" as="image" type="image/webp" fetchpriority="high">
Plaats dit zo vroeg mogelijk in de <head>. Voor achtergrondafbeeldingen buiten het scherm kun je ze uitstellen (defer) met een IntersectionObserver zodat ze pas laden wanneer de gebruiker in de buurt scrolt.
Om te verifiëren of je wijzigingen daadwerkelijk de echte user experience verbeteren, stel je Real User Monitoring in. Lab-scores vertellen je wat sneller zou moeten zijn. Field-data van echte bezoekers vertelt je wat daadwerkelijk sneller is.
Search Console flagged your site?
When Google flags your Core Web Vitals you need a clear diagnosis fast. I deliver a prioritized fix list within 48 hours.
Request Urgent Audit
