Hoe afbeeldingen en media Layout Shift veroorzaken (en hoe dit op te lossen)

Hoe afbeeldingen en media Layout Shift veroorzaken (en hoe dit op te lossen)

De 2025 Web Almanac plakt een getal op wat ik in de praktijk blijf zien: 62% van de mobiele pagina's heeft minstens één afbeelding zonder expliciete breedte en hoogte. Dat maakt ongedimensioneerde media de nummer één oorzaak van Cumulative Layout Shift op het web. En elk van deze verschuivingen is te voorkomen met technieken die al sinds 2019 bestaan.

Laatst beoordeeld door Arjen Karel in maart 2026

De browser weet niet hoe groot je afbeelding is

Elke layout shift door een afbeelding komt neer op één ding. De browser weet niet hoeveel ruimte er gereserveerd moet worden voordat de afbeelding laadt.

Wanneer de browser een <img> tag zonder dimensies tegenkomt, wordt de afbeelding op 0x0 pixels gerenderd. Het bestand arriveert, de browser berekent de lay-out opnieuw en alles onder de afbeelding springt naar beneden. Die sprong is je CLS.

Hoe width en height layout shift voorkomen

In 2019 en 2020 introduceerden alle grote browsers een functie die de werking van de attributen width en height veranderde. Browsers gebruiken ze nu om een aspect ratio te berekenen voordat de afbeelding downloadt.

Wanneer je dit schrijft:

<img src="hero.jpg" width="800" height="450" alt="Description">

Genereert de browser intern dit:

img[Attributes Style] {
    aspect-ratio: auto 800 / 450;
}

Geen afbeeldingsdata nodig. De browser kent de verhouding en reserveert de verticale ruimte.

Deze interne verhouding heeft de laagste CSS-prioriteit, dus elke CSS-regel die je schrijft overschrijft deze. Dat is belangrijk, want het is de reden waarom width: auto alles kapotmaakt (daarover zo meer).

Het keyword auto vertelt de browser: gebruik deze verhouding als een placeholder, maar schakel zodra de daadwerkelijke afbeelding laadt over naar de echte dimensies. Als je per ongeluk verkeerde waarden instelt (bijvoorbeeld width="4" height="3" op een 16:9 afbeelding), reserveert de browser in eerste instantie 4:3 ruimte en corrigeert dit vervolgens naar 16:9 wanneer de afbeelding laadt. Die correctie is een layout shift. Gebruik altijd de daadwerkelijke pixeldimensies.

Voeg voor responsive afbeeldingen deze CSS toe:

<style>
img {
    height: auto;
    max-width: 100%;
}
</style>

height: auto berekent de hoogte op basis van de verhouding. max-width: 100% voorkomt dat de afbeelding de container overschrijdt. De browser kent de breedte en de verhouding. Dat is genoeg.

Waarom width:auto je CLS kapotmaakt

Dit is degene die ik het meest zie en die de meeste debug-tijd verspilt. De ontwikkelaar stelt width en height in op elke afbeelding, doet alles goed in de HTML, draait Lighthouse, krijgt een groene score en lanceert het. Vervolgens stromen de CLS-klachten van echte gebruikers binnen.

De oorzaak ligt altijd ergens in de CSS. Eén globale regel maakt alles ongedaan:

<style>
img {
    width: auto;
    height: auto;
    max-width: 100%;
}
</style>

Het probleem is width: auto. Omdat de interne verhouding van de browser de laagste CSS-prioriteit heeft, wordt deze door elke regel overschreven. width: auto verwijdert de breedte die de browser gebruikte om de hoogte te berekenen. Beide dimensies worden onbekend. De afbeelding wordt op 0x0 gerenderd totdat het bestand is gedownload, en springt dan naar volledige grootte.

Het instellen van aspect-ratio in CSS lost dit niet op. Met width: auto behandelt de browser de breedte als 0 voordat de afbeelding laadt. Een aspect ratio berekend vanaf 0 levert nog steeds 0 op. Nul keer iets is nul.

Dit is het deel dat dit zo lastig te vangen maakt: het veroorzaakt alleen een verschuiving voor first-time bezoekers. Als de afbeelding in de browser cache staat, zijn de daadwerkelijke dimensies direct beschikbaar en treedt er geen verschuiving op. Jij, als ontwikkelaar, zult dit nooit op je eigen machine zien. Je testers zullen het niet zien. Je QA-team zal het niet zien. Alleen je echte gebruikers zien het bij hun eerste bezoek, wat exact het bezoek is dat Google meet voor CrUX.

Ik heb uren in calls gezeten met engineering teams die zwoeren dat hun CLS was gefixt omdat ze het lokaal niet konden reproduceren. Het was altijd dit. Controleer je CSS. Als je een globale width: auto op afbeeldingen hebt, is dat je probleem.

De oplossing:

<style>
img {
    height: auto;
    max-width: 100%;
}
</style>

Verwijder width: auto. Behoud height: auto en max-width: 100%. Dit is het patroon aanbevolen door web.dev.

Snelle check: klik met de rechtermuisknop op een willekeurige afbeelding op je site, kies "Inspect Element", en kijk naar de computed styles. Als je width: auto ziet, weet je nu wat je moet doen. Zie voor de volledige walkthrough fix layout shift caused door auto-sizing images.

Wanneer CSS aspect-ratio de betere keuze is

Width/height attributen zijn de standaardaanpak. Maar soms wil je dat CSS een specifieke verhouding afdwingt, ongeacht de inhoud van de afbeelding. Een hero banner die altijd 16:9 moet zijn, of een productkaart grid waar elke afbeelding dezelfde vorm nodig heeft:

<style>
img {
    aspect-ratio: 16 / 9;
    width: 100%;
}
</style>

Werkt in alle moderne browsers (Chrome 88+, Firefox 87+, Safari 15+) en op elk element, niet alleen afbeeldingen en video's.

Voor reguliere contentafbeeldingen zijn width/height attributen beter. Ze beschrijven de daadwerkelijke dimensies en corrigeren zichzelf wanneer de afbeelding laadt.

Je kunt beide combineren:

<style>
img {
    aspect-ratio: auto 16 / 9;
    width: 100%;
}
</style>

Het keyword auto betekent hier: gebruik 16/9 voordat de afbeelding laadt, schakel daarna over naar de natuurlijke verhouding. Ruimtereservering vóór het laden, accurate dimensionering erna.

Video's hebben hetzelfde probleem

Een video zonder width en height wordt op 0x0 gerenderd totdat de browser genoeg van het bestand downloadt om de metadata te lezen. Op een trage verbinding duurt dat seconden. De oplossing is identiek aan afbeeldingen:

<video src="demo.mp4" width="1280" height="720" autoplay muted loop></video>

Browsers berekenen een interne aspect-ratio: auto 1280 / 720 uit de attributen. Voeg height: auto; max-width: 100%; toe in CSS en je bent klaar.

Eén ding om in de gaten te houden: de poster image. Als je een poster instelt maar geen dimensies instelt op het video-element, neemt het element de grootte van de poster aan. Wanneer de video begint af te spelen en een andere resolutie heeft, krijg je een verschuiving. Stel width en height in zodat deze overeenkomen met de videoresolutie, niet met de poster.

Iframes hebben standaard een formaat van 300x150 pixels

Een iframe zonder expliciete dimensies heeft standaard een formaat van 300x150 pixels. Voor de meeste embeds (YouTube, Google Maps, social media posts) is dat verkeerd. Op het moment dat de embed laadt en van grootte verandert, verschuift alles eromheen.

In tegenstelling tot afbeeldingen, berekenen iframes niet automatisch een aspect ratio uit hun attributen. Je moet de dimensionering zelf instellen:

<style>
.responsive-iframe {
    width: 100%;
    height: auto;
    aspect-ratio: 16 / 9;
}
</style>

Dit vervangt de oude padding-top hack waarbij je het iframe verpakte in een container met padding-top: 56.25% en het absoluut positioneerde. De oude hack werkt nog steeds. aspect-ratio is schoner en heeft geen wrapper nodig.

Of laad het iframe helemaal niet

Voor YouTube, Vimeo, Google Maps en social embeds ben ik jaren geleden al gestopt met het inladen van iframes tijdens de page load. Het facade-patroon is op elke manier beter: toon een statische placeholder afbeelding met de correcte aspect ratio. Wanneer de gebruiker klikt, vervangt JavaScript deze door het echte iframe. Nul iframes, nul CLS, nul verspilde resources.

De verschuiving van de wissel gebeurt binnen 500ms na user input en wordt by design uitgesloten van CLS.

Zie voor implementatievoorbeelden perfecte YouTube embeds en Google Maps 100% PageSpeed.

Art direction: wanneer mobiele en desktop crops verschillende verhoudingen hebben

Art direction is wanneer je verschillende uitsnedes (crops) serveert op verschillende viewport breedtes. Een breed landschap op desktop, een strakker portret op mobiel. Het <picture> element handelt dit af met <source> elementen.

Het CLS-probleem: deze crops hebben meestal verschillende aspect ratios. De browser moet weten welke dimensies bij welk breakpoint horen. Je kunt width en height instellen op elke <source>:

<picture>
    <source
        media="(max-width: 799px)"
        srcset="hero-mobile.jpg"
        width="480" height="600">
    <source
        media="(min-width: 800px)"
        srcset="hero-desktop.jpg"
        width="1200" height="400">
    <img
        src="hero-desktop.jpg"
        width="1200" height="400"
        alt="Product hero image">
</picture>

Chrome en Safari pakken de juiste width/height van de <source> die actief is. Firefox doet dit niet. Er is een bug (bug 1694741) waarbij Firefox altijd de dimensies van de <img> fallback gebruikt, ongeacht de geselecteerde source. Als de mobiele crop een andere verhouding heeft, toont Firefox een verschuiving.

Als al je crops dezelfde verhouding delen (alleen verschillende resoluties), maakt deze bug niet uit. Hij treedt alleen op wanneer de verhoudingen verschillen tussen breakpoints.

Workaround voor Firefox

Totdat de fix is doorgevoerd, gebruik je CSS media queries die overeenkomen met de breakpoints in je <source> elementen:

<style>
picture img {
    width: 100%;
    height: auto;
}
@media (max-width: 799px) {
    picture img {
        aspect-ratio: 480 / 600;
    }
}
@media (min-width: 800px) {
    picture img {
        aspect-ratio: 1200 / 400;
    }
}
</style>

Dit overschrijft de interne verhouding van de browser met expliciete CSS per breakpoint. Werkt in alle browsers.

Houd dezelfde verhouding over alle srcset sources

Responsive afbeeldingen met srcset en sizes kunnen CLS veroorzaken als de width/height attributen niet overeenkomen met de geselecteerde source. De regel is simpel: alle afbeeldingen in een srcset moeten dezelfde aspect ratio delen. Als dat het geval is, is één set met width/height op de <img> voldoende:

<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="Hero image">

800:450 is dezelfde verhouding over alle drie de varianten. Ongeacht welke de browser kiest, de gereserveerde ruimte is correct.

Als je verhoudingen in dezelfde srcset mixt (één source in 16:9, een andere in 4:3), zal de gereserveerde ruimte verkeerd zijn voor ten minste één daarvan. Doe dit niet. Gebruik in plaats daarvan <picture> met <source> elementen als je verschillende verhoudingen nodig hebt.

Wanneer sizes verkeerd is

Het sizes attribuut vertelt de browser hoe breed de afbeelding gerenderd wordt op elk viewport formaat. Als dit niet overeenkomt met de daadwerkelijke CSS-lay-out, kiest de browser een source die te groot of te klein is. Dit veroorzaakt geen CLS (de verhouding blijft hetzelfde), maar het verspilt bandbreedte of produceert een wazige afbeelding.

sizes=auto voor lazy-loaded afbeeldingen

Chrome 126+ en Edge 126+ ondersteunen sizes="auto" op lazy-loaded afbeeldingen. De browser berekent de juiste grootte op basis van de CSS-lay-out in plaats van te vertrouwen op je handmatig geschreven sizes attribuut. Dit werkt niet op eager-loaded afbeeldingen omdat de browser de lay-outgrootte nodig heeft voordat de CSS is geparseerd.

Pas geen lazy loading toe above the fold

Lazy loading voor afbeeldingen above the fold veroorzaakt twee problemen tegelijk. Het vertraagt de LCP omdat loading="lazy" de resource verbergt voor de preload scanner. De browser kan de afbeelding pas ontdekken na de layout. En als de afbeelding ook nog geen dimensies heeft, krijg je een layout shift bovenop de vertraagde laadtijd.

De 2025 Web Almanac rapporteert dat 16% van de pagina's nog steeds lazy-load toepast op hun LCP-afbeelding. Dat is 16% van het web dat zijn belangrijkste afbeelding vertraagt voor nul voordeel.

loading="lazy" hoort thuis op afbeeldingen buiten de initiële viewport. Nergens anders.

1x1 pixel placeholders veroorzaken gigantische verschuivingen

JavaScript lazy loading scripts gebruiken vaak een kleine transparante GIF van 1x1 pixel als placeholder in src terwijl de echte URL in data-src zit. Wanneer de IntersectionObserver triggert, wisselt JavaScript ze om.

Dit veroorzaakt CLS omdat de 1x1 placeholder met een hoogte van 1px wordt gerenderd. Wanneer de 800x450 afbeelding laadt, springt het element van 1px naar 450px. Als je in 2026 nog steeds een JavaScript lazy loading library gebruikt, stop daar dan mee. Native loading="lazy" handelt de placeholder intern af en respecteert de width/height attributen. Het heeft sinds 2022 volledige browserondersteuning.

Als je een specifieke reden hebt om JavaScript lazy loading te behouden (intersection thresholds, fade-in animaties), gebruik dan een placeholder met dezelfde aspect ratio als de uiteindelijke afbeelding. Een 16x9 transparante SVG in plaats van 1x1.

LQIP goed uitgevoerd

Een geblurde thumbnail placeholder ziet er beter uit dan lege ruimte. De sleutel: behoud de aspect ratio. Als je uiteindelijke afbeelding 800x450 is, zou je LQIP een piepkleine versie (10x6 of 20x11) met dezelfde verhouding moeten zijn. Schaal het op met CSS en pas een blur filter toe. Wanneer de echte afbeelding laadt, vervangt deze de blur met dezelfde dimensies. Geen verschuiving.

Next.js doet dit automatisch. De Image component genereert width, height en blurDataURL tijdens build time. Nul CLS.

Gebruik object-fit voor containers met vaste grootte

Productkaart grids waarbij elke kaart dezelfde hoogte heeft maar de afbeeldingen verschillende verhoudingen. Ik zie dit patroon voortdurend:

<style>
.product-image {
    width: 100%;
    aspect-ratio: 1 / 1;
    object-fit: cover;
    object-position: center;
}
</style>
<img
    src="product.jpg"
    width="400" height="600"
    class="product-image"
    alt="Product name">

aspect-ratio: 1 / 1 forceert een vierkant. object-fit: cover vult het vierkant en snijdt de overloop (overflow) weg. De grootte is vastgezet voordat de afbeelding laadt.

Dit is ook hoe je CSS background images vervangt door correcte <img> elementen. Background images kunnen niet via lazy loading geladen worden, kunnen geen fetchpriority gebruiken en de preload scanner vindt ze pas wanneer het CSS-bestand is geparseerd. Een <img> met object-fit: cover geeft je alle controle over performance die een background image mist.

Auto-playing carousels produceren oneindige CLS

Slide transities die left, width of margin animeren, triggeren een layout herberekening. Omdat autoplay geen user input is, telt elke verschuiving mee voor CLS. Een auto-playing carousel met layout-triggerende transities kan oneindig CLS produceren.

Zet de container dimensies vast met een vaste aspect ratio, animeer met transform: translateX() in plaats van left of margin-left (transforms draaien op de GPU en triggeren nooit layout), en als je echt autoplay moet gebruiken, mogen de dimensies van de slide container niet veranderen. Elke resize telt als CLS.

In een non-autoplay carousel gebeuren de meeste transities binnen 500ms na een gebruikersklik en worden ze uitgesloten van CLS. Autoplay neemt die bescherming weg. De web.dev carousel gids behandelt de implementatiedetails.

SVG, containment en andere edge cases

SVG's geladen via <img> hebben width en height nodig op de tag, net als rasterafbeeldingen. Inline <svg> elementen hebben expliciete dimensies nodig of een viewBox met CSS aspect-ratio. Een SVG met geen van beide heeft standaard een formaat van 300x150.

Voor embeds die je niet kunt controleren (ad slots, third-party widgets, user-generated content), gebruik je CSS containment om te voorkomen dat de verschuiving zich verspreidt:

<style>
.embed-container {
    min-height: 250px;
    contain: layout style;
}
</style>

contain: layout style vertelt de browser dat niets binnen deze container invloed heeft op de lay-out daarbuiten. De embed kan verschuiven, groeien of krimpen. De rest van de pagina blijft op zijn plek.

Voor below-the-fold secties met zware media slaat content-visibility: auto met contain-intrinsic-size layout over voor content buiten het scherm. Zonder contain-intrinsic-size heeft het element nul hoogte en is de expansie wanneer de gebruiker ernaartoe scrollt een layout shift:

<style>
.below-fold-gallery {
    content-visibility: auto;
    contain-intrinsic-size: auto 500px;
}
</style>

Het keyword auto betekent: start met 500px als een schatting, maar zodra de browser het rendert en de echte hoogte kent, onthoud die waarde.

Hoe je afbeelding CLS vindt

Je zult afbeelding CLS niet vangen op je eigen machine. Je browser cache heeft de dimensies al. Je hebt first-time visitor condities nodig of echte gebruikersdata.

Real User Monitoring

Start met CoreDash of een andere RUM tool. CLS attributiedata toont exact welke elementen verschoven zijn. Navigeer naar CLS en kijk in de attributie Element tabel. Dit vertelt je exact welke elementen verschoven. Om afbeeldingen te vinden, filter je simpelweg op image en je krijgt een tabel van alle image elementen die geraakt zijn door layout shifts, gesorteerd op impact.

Chrome DevTools

Schakel de cache uit in de Network tab, throttle naar Slow 4G, activeer screenshots, en herlaad. Let op visuele sprongen. Open vervolgens het Performance panel en zoek naar "Layout Shift" entries. Klik op een shift om de node en de score te zien, en of er recente user input was.

Core Web Vitals Visualizer

De Core Web Vitals Visualizer extensie markeert elke layout shift met een gekleurde overlay. Ik gebruik dit als eerste stap voordat ik het Performance panel open. Herlaad met de extensie actief en je ziet exact wat er bewoog.

Lighthouse vangt een deel ervan

Lighthouse markeert afbeeldingen zonder width en height. Maar het mist het width: auto probleem volledig omdat de HTML-attributen aanwezig zijn. CSS overschrijft ze en Lighthouse controleert geen computed styles. Dit is waarom ik nooit vertrouw op een groene Lighthouse CLS-score zonder ook velddata te controleren.

Quick fix checklist

Waar het web staat wat betreft afbeelding CLS

De cijfers van de 2025 Web Almanac:

• 62% van de mobiele pagina's heeft minstens één ongedimensioneerde afbeelding. Een daling ten opzichte van 66% in 2024. Nog steeds de meerderheid.
• 65% van de desktop pagina's heeft ongedimensioneerde afbeeldingen. Een daling ten opzichte van 69%.
• Op het 75e percentiel (p75) heeft een desktop pagina 9 ongedimensioneerde afbeeldingen. Mobiel heeft er 8.
• Op het 90e percentiel (p90): 25 op desktop, 22 op mobiel.
• Mediane hoogte van ongedimensioneerde afbeeldingen: 111px op desktop, 98px op mobiel. Genoeg om een alinea te verschuiven.
• 72% van de desktop en 81% van de mobiele origins haalt CLS. Een stijging ten opzichte van 62% in 2021.
• 40% van de mobiele pagina's gebruikt nog steeds non-composited animaties die op zichzelf al CLS veroorzaken.

CLS is sterker verbeterd dan elke andere Core Web Vital over de afgelopen vier jaar. Ongedimensioneerde afbeeldingen zijn nog steeds de grootste veroorzaker. Fix dit ene probleem en layout shifts verdwijnen op de meeste sites.

Gerelateerde gidsen

• Wat is Cumulative Layout Shift (CLS): De complete gids. Formule, thresholds, session windows en alle CLS oorzaken buiten afbeeldingen.
• Vind en Fix CLS Issues: Stap-voor-stap diagnoses met RUM data, DevTools en oplossingen voor elke oorzaak.
• Fix layout shift caused door auto-sizing images: De volledige width: auto walkthrough.
• Optimaliseer afbeeldingen voor Core Web Vitals: Preloading, responsive afbeeldingen, formaten, prioritering.
• Layout shift veroorzaakt door CSS transities: Hoe layout-triggerende animaties CLS veroorzaken.
• Perfecte YouTube embeds: Het facade-patroon voor nul CLS.
• Google Maps 100% PageSpeed: Dezelfde facade-aanpak voor Maps.