Achtergrondafbeeldingen zijn een ramp

Achtergrondafbeeldingen zijn een ramp

Ken je me of heb je me weleens horen spreken, dan heb je me vast al over achtergrondafbeeldingen gehoord. Ken je me nog niet: ik heb echt een enorme hekel aan achtergrondafbeeldingen. Dit is waarom ik er zo'n hekel aan heb, hoe je snel pagina's met achtergrondafbeeldingen vindt en hoe je ze fixt.

Laatst gecontroleerd door Arjen Karel in maart 2026

Waarom achtergrondafbeeldingen slecht zijn voor de Core Web Vitals

Bij het laden van een webpagina heeft elk element een eigen tijd en plek. Met moderne technieken zoals deferring, preloading, async loading, scheduling en het instellen van fetchpriority krijgen we vrijwel alle kritieke resources prima onder controle. Behalve achtergrondafbeeldingen! 

Kijk naar dit praktijkvoorbeeld:

Dit patroon zie ik dagelijks, vooral op WordPress-sites. Alle normale afbeeldingen worden lazy loaded en een paar afbeeldingen (in dit geval de social icons in de footer) zijn achtergrondafbeeldingen. Raad eens wat er gebeurt?

<html>
<head>
    <style>
        footer {
            /* een margin van 100vh zet de footer offscreen! */
            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 is 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 al: de offscreen achtergrondafbeeldingen belanden eerder in de downloadwachtrij dan de veel belangrijkere 'hero.jpg'-afbeelding die meestal het largest contentful paint-element op de pagina wordt.

Maar dat is nog niet alles!

Zoals ik al zei: achtergrondafbeeldingen zijn een ramp! Want los van de vreemde prioriteit die ze soms krijgen, missen achtergrondafbeeldingen alle handige features van normale afbeeldingen!

• 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's fetchpriority="high" op hun LCP-afbeelding.
• Responsive afbeeldingsbronnen: de functie image-set() voor achtergrondafbeeldingen biedt niet dezelfde mogelijkheden als srcset en het <picture>-element.
• Geen width- en height-attribuut. Kun je die simpele width- en height-attributen niet instellen, dan kan de browser geen ruimte reserveren voor de afbeelding. Dat veroorzaakt layout shift (CLS). Je eindigt met CSS-workarounds, en meer code is bij gelijke complexiteit altijd trager dan minder code!
• Geen alt-tekst: achtergrondafbeeldingen hebben geen alt-attribuut. Dat schaadt de toegankelijkheid en betekent dat Google Images ze niet kan indexeren.

Achtergrondafbeeldingen die via url() laden, zijn geldige LCP-kandidaten. Een trage achtergrondafbeelding duikt dus gewoon op als je LCP, maar je hebt geen van bovenstaande tools om hem 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 metingen van Google zelf grofweg 400ms toe aan de mediane LCP.

Volgens de 2025 Web Almanac gebruikt 9% van de mobiele pagina's nog altijd een via CSS geïnitieerde afbeelding als LCP-element. Dat cijfer is sinds 2022 niet veranderd. Op sites die worden gemonitord door CoreDash, verbeterde het vervangen van een hero-achtergrondafbeelding door een <img>-tag de mediane LCP met 35%.

Zo vind je snel alle achtergrondafbeeldingen op een pagina

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 een overzichtelijke tabel met alle namen van de achtergrondafbeeldingen en de initiators.

Zo voorkom je achtergrondafbeeldingen

Achtergrondafbeeldingen zijn makkelijk te vermijden. Hoe je dat doet, hangt af van de afbeelding zelf. Er zijn grofweg 2 methodes.

Bij 'normale afbeeldingen'

Je gelooft het bijna niet, maar in de meeste gevallen waarin ik achtergrondafbeeldingen tegenkom, heeft het achtergronddeel van de afbeelding niet eens een doel. De afbeelding moet gewoon 'ergens op de pagina staan' en background-image:url() wordt daarvoor misbruikt.
Is dat het geval, voeg dan gewoon een normale image-tag toe en verwijder de achtergrondafbeelding uit de stylesheet.

Bij cover images:

Cover images zijn afbeeldingen die een parent container volledig vullen. Achtergrondafbeeldingen gebruiken als cover image is ergens wel logisch: heel vroeger was dat de enige manier, en mensen houden nu eenmaal vast aan wat ze kennen. Gelukkig kan het tegenwoordig veel beter. Tijd voor een fix!
Bij cover images verwijder je simpelweg de style   background-image: url(hero.jpg); background-size: cover;, plaats je een normale afbeelding in diezelfde container en pas je de CSS als volgt aan:

<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 volwaardige afbeelding met de attributen width, height, loading, decoding, srcset, fetchpriority en alt. Precies wat de browser nodig heeft om hem efficiënt te laden.

Wanneer je een achtergrondafbeelding moet behouden

Soms heb je echt een CSS-achtergrondafbeelding nodig: bij herhalende patronen, decoratieve overlays of wanneer het CMS je geen andere optie geeft. In die situaties preload je de afbeelding, zodat de browser hem vroeg ontdekt:

<link rel="preload" href="hero.webp" as="image" type="image/webp" fetchpriority="high">

Plaats dit zo vroeg mogelijk in de <head>. Voor offscreen achtergrondafbeeldingen kun je ze deferren met een IntersectionObserver, zodat ze pas laden zodra de bezoeker in de buurt scrolt.

Om te controleren of je wijzigingen de ervaring van echte gebruikers echt verbeteren, richt je Real User Monitoring in. Lab scores vertellen je wat sneller zou moeten zijn. Field data van echte bezoekers laat zien wat er echt sneller is.