Cumulative Layout Shift (CLS) Problemen Identificeren en Oplossen

Voordat je iets aanpast, bevestig dat je daadwerkelijk een CLS-probleem hebt. Log in op Google Search Console, navigeer naar Core Web Vitals en controleer zowel mobiel als desktop.

Als Google URL's markeert met "CLS-probleem: meer dan 0.25" of "CLS-probleem: meer dan 0.1", heb je bevestiging vanuit het Chrome User Experience (CrUX) Report dat echte gebruikers layout shifts ervaren op je site.

In tegenstelling tot LCP en INP, waar ruwe rekenkracht en netwerksnelheid belangrijk zijn, kunnen CLS-problemen specifiek zijn voor het apparaat of schermformaat. Wanneer een vergelijkbaar probleem invloed heeft op mobiel en desktop (afbeeldingen zonder afmetingen, font swaps, geïnjecteerde content), kan desktop door het schermformaat een veel grotere CLS-waarde rapporteren (omdat een groter deel van de zichtbare viewport beïnvloed kan zijn). Search Console groepeert URL's, dus het vertelt je welke paginatypes zijn getroffen, maar niet welke elementen verschuiven. Daarvoor heb je RUM nodig.

Search Console bevestigt dat het probleem bestaat, maar geeft je vrijwel niets om mee te werken. Je moet uitzoeken welke elementen verschuiven, op welke pagina's en onder welke omstandigheden. Daarvoor heb je een RUM-tool nodig.

Ik heb CoreDash gebouwd om precies deze vragen te beantwoorden. Je voegt één script-tag toe en het begint met het verzamelen van CLS attributiedata van elke echte bezoeker. Het belangrijkste datapunt voor CLS debugging is het verschuivende element: de daadwerkelijke DOM node die bewoog. Zonder die informatie ben je blind aan het debuggen.

Verschuivende elementen vinden

Begin met het bekijken van je CLS-data gegroepeerd per element. Navigeer in CoreDash naar de CLS-pagina en bekijk de datatabel gesorteerd op "CLS by Element". Dit toont aan welke elementen de meeste layout shift veroorzaken bij al je bezoekers. Klik op de ergste om alle statistieken te filteren voor pagina's waar dat element verschoof.

Vind welke pagina's zijn getroffen

Na het filteren op het meest impactvolle verschuivende element, controleer je de URL breakdown. CLS-problemen kunnen site-breed of template-breed zijn. Nu weten we of de CLS is geclusterd op specifieke paginatypes: productpagina's met afbeeldingengalerijen, blogposts met advertentieslots, of landingspagina's met hero-animaties. Weten welke pagina's falen vertelt je waar je de focus op moet leggen.

Controleer nieuwe bezoekers vs. terugkerende bezoekers

Dit is nog een snelle check die ik doe, en het is belangrijker dan de meeste mensen denken. Font-swap CLS gebeurt alleen wanneer het lettertype niet is gecachet. Afbeelding-CLS door width: auto gebeurt alleen wanneer de afbeelding niet in de browser cache staat. Als je CLS veel slechter is voor nieuwe bezoekers, heb je te maken met een cache-afhankelijke verschuiving die jij, als developer, nooit op je eigen machine zult zien, tenzij je de cache uitschakelt (tip: schakel altijd je Chrome cache uit ... maar dat is een ander verhaal voor een andere keer).

Controleer apparaatypes en viewport formaten

CLS toont doorgaans een ander mobiel/desktop patroon dan LCP en INP. Responsive lay-outs kunnen verschuivingen introduceren die alleen optreden bij specifieke viewport-breedtes en -hoogtes. Een advertentieslot dat problemen veroorzaakte op desktop bevindt zich misschien niet eens in de mobiele viewport. Een navigatiemenu animeert mogelijk anders op kleinere breakpoints. Groepeer je CLS-data op apparaattype om te weten waar ze optreden.

Je RUM-data heeft je verteld welke elementen verschuiven en waarom. Reproduceer nu het probleem lokaal en ontdek wat de oorzaak is.

Gebruik de Core Web Vitals Visualizer

De snelste manier om layout shifts te zien is met de Core Web Vitals Visualizer Chrome extensie. Laad de pagina, klik op het extensie-icoon en herlaad. Elke layout shift wordt uitgelicht met een gekleurde overlay die precies toont wat er verschoof en hoeveel. Ik gebruik dit als mijn eerste stap voordat ik het Performance paneel open, omdat het direct een visueel antwoord geeft.

Kopieer de omstandigheden in Chrome en controleer de netwerk screenshots

CLS-problemen zijn vaak onzichtbaar met een warme cache. Open DevTools, schakel de cache uit in de Network tab en pas throttling toe naar "Slow 4G" (mijn favoriet, dit toont je CLS veroorzaakt door race conditions). Klik nu op het tandwiel-icoon en schakel caching uit (terwijl DevTools open is). Dit simuleert de omstandigheden die je nieuwe bezoekers ervaren. Ga naar de Network tab en schakel screenshots in. Herlaad nu de pagina en let op verschuivingen.

Gebruik het Chrome Performance paneel

De meeste layout shifts zijn makkelijk te spotten als je weet hoe, maar soms ontgaan ze je. Dat is het moment om Chrome DevTools te openen (Ctrl+Shift+I) en naar het Performance paneel te gaan voor gedetailleerde debugging. Druk op Ctrl+Shift+E om te herladen en op te nemen. Nadat de pagina is geladen, scroll je een paar keer omhoog en omlaag. Stop de opname.

Zoek naar de "Layout Shifts" track. Elke verschuiving verschijnt als een gekleurd blokje. Klik op een shift om te zien:

• De verschuivende node: het DOM-element dat bewoog
• De shift score: impact fraction vermenigvuldigd met distance fraction
• hadRecentInput: of er gebruikersinvoer voorafging aan de shift (klikken en tikken krijgen een grace period van 500ms, maar scrollen niet)

Let op wanneer de shifts plaatsvinden. Verschuivingen tijdens het laden van de pagina wijzen op afbeeldingen zonder afmetingen, font swaps of CSS transities. Verschuivingen tijdens het scrollen wijzen op scroll-getriggerde animaties die layout-eigenschappen gebruiken.

Snelle test: schakel alle transities uit

CSS-transities die layout-eigenschappen animeren zijn een stiekeme oorzaak van CLS, omdat ze alleen verschuiven tijdens de laadfase en moeilijk te reproduceren zijn. Plak deze snippet in de console, voer een hard reload uit met uitgeschakelde cache en vergelijk de CLS:

document.head.insertAdjacentHTML('beforeend',
  '<style>*{transition-property:none!important}</style>');

Als je CLS daalt na het uitschakelen van transities, heb je de oorzaak gevonden. Gebruik de CSS transition debugging gids om de specifieke verantwoordelijke transities te vinden.

const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    if (!entry.hadRecentInput) {
      console.log('Layout shift:', {
        value: entry.value,
        sources: entry.sources?.map(s => ({
          node: s.node,
          previousRect: s.previousRect,
          currentRect: s.currentRect
        }))
      });
    }
  }
});
observer.observe({ type: 'layout-shift', buffered: true });

Je weet welke elementen verschuiven en waarom. Tijd om ze te fixen. CLS heeft geen sequentiële fases zoals LCP. In plaats daarvan hebben layout shifts duidelijke oorzaakcategorieën. Hier zijn de meest voorkomende, in de volgorde waarin ik ze tegenkom tijdens audits.

1. Afbeeldingen, video's en iframes zonder afmetingen

Dit is wereldwijd oorzaak nummer één van CLS. De 2025 Web Almanac rapporteert dat 62% van de mobiele pagina's minstens één afbeelding zonder afmetingen heeft. De oplossing: neem altijd width en height attributen op in <img>, <video> en <iframe> tags.

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

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

Kijk uit voor width: auto in je CSS. Deze enkele declaratie overschrijft de berekening van de aspect ratio van de browser en veroorzaakt layout shifts, zelfs als je breedte en hoogte hebt ingesteld in de HTML. Ik heb dit op tientallen sites gezien. De developer deed alles goed in de opmaak, maar een algemene CSS-regel zoals img { width: auto; height: auto; max-width: 100%; } maakte alles ongedaan. Voor de volledige uitleg, zie layout shift door auto-sizing afbeeldingen oplossen. Voor een complete gids over alle oorzaken van beeld- en media-CLS (video's, iframes, art direction, responsive images, lazy loading, placeholders), zie Hoe Afbeeldingen en Media Layout Shift Veroorzaken.

2. Web Font Swaps

Wanneer een web font laadt en de fallback font vervangt, veroorzaakt het verschil in grootte een layout shift. De 2025 Web Almanac laat zien dat slechts 11% van de pagina's web fonts preload. Dat betekent dat de overgrote meerderheid van de sites kwetsbaar is voor font-swap CLS.

De oplossing bestaat uit twee delen. Zorg er allereerst voor dat de fallback font overeenkomt met de dimensies van het web font door middel van metric overrides:

<style>
@font-face {
    font-family: 'My Font Fallback';
    src: local('Arial');
    size-adjust: 105.2%;
    ascent-override: 93%;
    descent-override: 24%;
    line-gap-override: 0%;
}

@font-face {
    font-family: 'My Font';
    src: url('/fonts/myfont.woff2') format('woff2');
    font-display: swap;
}

body {
    font-family: 'My Font', 'My Font Fallback', sans-serif;
}
</style>

Gebruik een Fallback Font Generator om de juiste override-waarden te berekenen voor jouw font pairing. Ten tweede, versnel de levering: self-host je fonts, preload je kritieke fontbestand en gebruik WOFF2 met subsetting. Voor een complete strategie, zie responsive web font loading en zorgen dat tekst zichtbaar blijft tijdens het laden van web fonts.

3. CSS Animaties en Transities

Volgens de 2025 Web Almanac gebruikt 40% van de mobiele pagina's non-composited animaties. Deze animeren eigenschappen zoals width, height, top, left, margin en padding, wat bij elke frame een layout recalculation triggert.

De meest voorkomende boosdoener is transition: all. Wanneer een developer transition: all .3s ease schrijft, wordt elke eigenschapswijziging geanimeerd, inclusief layout-eigenschappen. Tijdens het laden van de pagina produceren elementen die van hun unstyled naar gestylede status overgaan layout shifts die met tussenpozen gebeuren en bijna onmogelijk consistent te reproduceren zijn. Ik zie dit patroon constant.

De oplossing: vervang layout-triggerende eigenschappen door composited eigenschappen.

• Gebruik transform: translateY() in plaats van top/bottom
• Gebruik transform: translateX() in plaats van left/right
• Gebruik transform: scale() in plaats van width/height
• Gebruik opacity in plaats van visibility gecombineerd met hoogteveranderingen
• Gebruik nooit transition: all. Specificeer de exacte eigenschap: transition: background-color .2s ease

transform en opacity draaien volledig op de compositor thread en triggeren nooit de layout. Voor het volledige debugging proces, zie layout shift veroorzaakt door CSS-transities.

4. Advertenties, Embeds en Dynamisch Geïnjecteerde Content

Advertenties laden laat en drukken content naar beneden. Cookie consent banners verschijnen en verschuiven de pagina. AJAX requests injecteren nieuwe content zonder eerst ruimte te reserveren. Dit is allemaal hetzelfde probleem: er verschijnt iets op de pagina waarvan de browser tijdens het renderen nog niets wist.

De oplossing voor dit alles is ruimte reserveren. Voor advertentieslots stel je een min-height in die overeenkomt met de verwachte advertentiegrootte:

<style>
.ad-slot {
    min-height: 250px;
    contain: layout style;
}
@media (min-width: 600px) {
    .ad-slot { min-height: 90px; }
}
</style>

De declaratie contain: layout style isoleert de advertentiecontainer van de rest van de pagina. Gebruik voor cookiebanners position: fixed om ze als overlay te plaatsen in plaats van content naar beneden te drukken. Voor AJAX content reserveer je ruimte met min-height. Je hoeft niet exact te raden: een verschil van 50px levert veel minder CLS op dan een shift van 400px door helemaal geen reservering.

Voor embeds van derden zoals YouTube, Google Maps en chat widgets, gebruik je het facade-patroon: toon een statische placeholder en laad de echte embed pas zodra de gebruiker hiermee interacteert. Nul CLS, nul verspilde resources.

5. Scroll-Getriggerde Layout Shifts

Dit is de CLS-oorzaak die Lighthouse nooit zal oppikken. Lighthouse scrollt niet over de pagina, waardoor scroll-getriggerde layout shifts volledig onzichtbaar zijn in labtesten. De enige manier om ze te vinden is met RUM-data of door een trace op te nemen in het Performance paneel terwijl je handmatig scrollt.

Het meest voorkomende voorbeeld is een hide-on-scroll header die de top eigenschap animeert. Hier is iets wat de meeste developers niet weten: scrollen is geen uitsluitende input in de Layout Instability specificatie. Klikken en tikken krijgen een grace period van 500ms. Scrollen niet. Elke layout shift die door scrollen wordt getriggerd, telt mee voor je CLS-score.

De oplossing: gebruik transform: translateY() in plaats van top voor elke scroll-getriggerde animatie. Hetzelfde geldt voor parallax effecten, krimpende navigatiebalken en aan scrollen gekoppelde progress bars. Als het beweegt tijdens het scrollen, animeer het dan met transform. Voor de volledige uitleg met videovoorbeelden, zie hoe scroll-getriggerde animaties CLS veroorzaken.