Waarom Cumulative Layout Shift Je Gebruikers Wegjaagt
Je kent het wel. Je leest een artikel op je telefoon, je vinger beweegt richting een link — en precies op dat moment springt de hele pagina. Je klikt op een advertentie in plaats van op het artikel dat je wilde openen. Of erger nog: je drukt op "Annuleren" terwijl je eigenlijk "Bevestigen" wilde kiezen.
Frustrerend? Absoluut. En het heeft een naam.
Cumulative Layout Shift (CLS) is de Core Web Vital die deze irritatie meetbaar maakt. En in 2026 weegt Google deze metric zwaarder dan ooit bij het bepalen van je zoekrangschikking. Ik heb de afgelopen jaren tientallen sites geoptimaliseerd waar CLS de boosdoener bleek — en eerlijk gezegd verbaast het me nog steeds hoe vaak dezelfde fouten terugkomen.
In deze gids neem ik je mee door alles wat je moet weten over CLS: hoe het wordt berekend, wat de meest voorkomende oorzaken zijn, en — belangrijker nog — hoe je elke oorzaak systematisch oplost met concrete codevoorbeelden. Of je nu een frontend-ontwikkelaar bent die een bestaande site optimaliseert of een architect die een nieuw project opzet, na het lezen hiervan heb je een compleet arsenaal aan technieken om je CLS-score onder de 0,1 te krijgen en te houden.
Hoe CLS Wordt Berekend: De Wiskunde Achter de Score
Oké, even de theorie in. Om CLS effectief te kunnen optimaliseren, moet je begrijpen hoe de score tot stand komt. De browser meet individuele layout shifts en combineert die tot een totaalscore.
De Layout Shift Score-formule
Elke individuele layout shift wordt berekend met twee factoren:
- Impact Fraction: het percentage van de viewport dat door de verschuiving wordt beïnvloed. Als een element van 300 pixels hoog 200 pixels naar beneden schuift op een viewport van 800 pixels hoog, is de impact fraction (300 + 200) / 800 = 0,625.
- Distance Fraction: de afstand die elementen verschuiven als fractie van de viewport. In ons voorbeeld: 200 / 800 = 0,25.
De layout shift score is dan simpelweg: impact fraction × distance fraction. In ons voorbeeld: 0,625 × 0,25 = 0,15625. Dat is al ruim boven de drempel van 0,1 — en dat is slechts één verschuiving. Laat dat even bezinken.
Session Windows: Hoe CLS Over Tijd Wordt Gemeten
Hier wordt het interessant (en voor veel ontwikkelaars verwarrend). CLS gebruikt het concept van session windows om verschuivingen te groeperen. Een session window begint bij de eerste layout shift en eindigt wanneer er 1 seconde geen verschuivingen plaatsvinden, of na maximaal 5 seconden. De uiteindelijke CLS-score is de maximale session window score gedurende de hele levenscyclus van de pagina — niet de som van alle verschuivingen.
Dit detail wordt vaak over het hoofd gezien. Het betekent dat vijf kleine verschuivingen binnen hetzelfde session window een hogere CLS kunnen veroorzaken dan één grote verschuiving in een apart window. Verrassend, toch?
Drempelwaarden
Google hanteert de volgende drempelwaarden, gemeten op het 75e percentiel van paginalaadmomenten:
- Goed: 0,1 of lager
- Verbetering nodig: tussen 0,1 en 0,25
- Slecht: hoger dan 0,25
De Zes Meest Voorkomende Oorzaken van CLS
Voordat je CLS kunt oplossen, moet je weten waar de verschuivingen vandaan komen. Dit zijn de zes boosdoeners die in mijn ervaring verantwoordelijk zijn voor het overgrote deel van alle layout shifts.
1. Afbeeldingen en Video zonder Afmetingen
Dit is veruit de nummer één oorzaak van CLS op het web. Wanneer een browser een <img>-tag tegenkomt zonder width en height attributen, reserveert hij geen ruimte totdat de afbeelding is gedownload. Zodra de afmetingen bekend zijn, wordt de rest van de pagina omlaag geduwd. Simpel, maar het komt nog steeds schrikbarend vaak voor.
2. Webfonts die Layout Shifts Veroorzaken
Webfonts zijn een sluipende CLS-veroorzaker. Het probleem manifesteert zich op twee manieren: FOIT (Flash of Invisible Text), waarbij tekst onzichtbaar blijft tot het font is geladen, en FOUT (Flash of Unstyled Text), waarbij tekst eerst in een systeemfont wordt weergegeven en dan plotseling van lettertype wisselt. Beide kunnen verschuivingen veroorzaken wanneer de afmetingen van het webfont afwijken van het fallback-font.
3. Advertenties en Embeds van Derden
Advertenties, social media embeds en iframes laden asynchroon en hebben vaak dynamische afmetingen. Wanneer ze verschijnen, duwen ze bestaande content opzij.
Hoe hoger op de pagina deze elementen staan, hoe groter de impact op CLS. Dat is logisch als je erover nadenkt — er is simpelweg meer content die kan verschuiven.
4. Dynamisch Geïnjecteerde Content
Banners, cookie-meldingen, nieuwsbriefinschrijvingen — alles wat via JavaScript boven bestaande content wordt geplaatst, veroorzaakt layout shifts. Elke keer dat je iets boven de huidige viewport invoegt, schuift alles eronder naar beneden.
5. CSS Animaties die Layout Triggeren
Animaties die properties zoals height, width, top of margin wijzigen, triggeren layout-herberekeningen. Dit kan onverwachte verschuivingen veroorzaken, vooral bij complexe paginalayouts.
6. Late Laden van CSS of JavaScript
Wanneer stylesheets of scripts laat laden en de layout van al gerenderde elementen wijzigen, verschuift de hele pagina. Dit komt vooral voor bij render-blocking resources die asynchroon worden geladen zonder adequate fallback-styling. Een klassieke valkuil.
Afbeeldingen Stabiliseren: width, height en aspect-ratio
De eenvoudigste en meest effectieve CLS-verbetering? Expliciete afmetingen toevoegen aan alle media-elementen. Moderne browsers gebruiken width en height attributen om de aspect ratio te berekenen nog voordat de afbeelding geladen is.
<!-- Altijd width en height specificeren -->
<img
src="/images/hero.webp"
alt="Hero afbeelding"
width="1200"
height="630"
loading="lazy"
decoding="async"
>De browser berekent hieruit automatisch een aspect ratio van 1200:630 en reserveert de juiste hoeveelheid ruimte, zelfs als de afbeelding responsive schaalt via CSS. Zo simpel kan het zijn.
De CSS aspect-ratio Property
Voor responsieve layouts waar je meer controle nodig hebt, is de aspect-ratio property je beste vriend. In 2026 wordt deze door alle grote browsers volledig ondersteund, dus er is geen excuus meer om 'm niet te gebruiken.
/* Responsieve afbeelding met stabiele layout */
.hero-image {
width: 100%;
height: auto;
aspect-ratio: 16 / 9;
object-fit: cover;
}
/* Video container met vaste verhouding */
.video-wrapper {
width: 100%;
aspect-ratio: 16 / 9;
background-color: #1a1a2e;
}
/* Vierkante productafbeelding */
.product-thumbnail {
width: 100%;
aspect-ratio: 1 / 1;
object-fit: contain;
background-color: #f5f5f5;
}Skeleton Screens met Correcte Verhoudingen
Bij asynchroon geladen content zijn skeleton screens essentieel om ruimte te reserveren. Maar — en dit is belangrijk — de skeleton moet dezelfde aspect ratio hebben als de uiteindelijke content. Anders veroorzaak je juist extra verschuivingen, en dat is erger dan helemaal geen skeleton.
/* Skeleton placeholder die exact past bij de uiteindelijke content */
.card-skeleton {
aspect-ratio: 4 / 3;
background: linear-gradient(90deg, #e0e0e0 25%, #f0f0f0 50%, #e0e0e0 75%);
background-size: 200% 100%;
animation: shimmer 1.5s infinite;
border-radius: 8px;
}
@keyframes shimmer {
0% { background-position: 200% 0; }
100% { background-position: -200% 0; }
}
/* Tekst skeleton met min-height */
.text-skeleton {
min-height: 1.2em;
background-color: #e0e0e0;
border-radius: 4px;
margin-bottom: 0.5em;
}Webfonts Zonder Layout Shifts: Drie Strategieën
Fonts zijn verantwoordelijk voor een verrassend groot deel van alle CLS-problemen. Eerlijk gezegd onderschatten de meeste ontwikkelaars dit. Hier zijn drie strategieën, van eenvoudig tot geavanceerd.
Strategie 1: font-display: optional
De meest radicale maar ook meest effectieve aanpak. Met font-display: optional geef je de browser een uiterst kort tijdsvenster (circa 100ms) om het font te laden. Lukt dat niet? Dan wordt het systeemfont gebruikt voor de rest van de paginalevensduur. Geen fontwissel, geen CLS. Klaar.
@font-face {
font-family: 'MijnFont';
src: url('/fonts/mijnfont.woff2') format('woff2');
font-display: optional;
font-weight: 400;
font-style: normal;
}Het nadeel? Bij het eerste bezoek kan het systeemfont worden weergegeven in plaats van je merkfont. Maar bij herhaalde bezoeken staat het font in de cache en wordt het wél direct gebruikt. Voor de meeste websites is dit een prima afweging.
Strategie 2: font-display: swap met size-adjust
Wil je dat je webfont altijd wordt weergegeven maar toch CLS minimaliseren? Dan is dit je strategie. Combineer font-display: swap met de size-adjust, ascent-override en descent-override descriptors om het systeemfont qua afmetingen zo dicht mogelijk bij het webfont te brengen.
/* Het echte webfont */
@font-face {
font-family: 'Inter';
src: url('/fonts/inter-var.woff2') format('woff2');
font-display: swap;
font-weight: 100 900;
}
/* Fallback font met aangepaste metrics */
@font-face {
font-family: 'Inter-Fallback';
src: local('Arial');
size-adjust: 107.64%;
ascent-override: 90.49%;
descent-override: 22.48%;
line-gap-override: 0%;
}
body {
font-family: 'Inter', 'Inter-Fallback', sans-serif;
}Tools zoals Fontaine en het next/font-systeem van Next.js berekenen deze waarden automatisch voor je. Hiermee verklein je de CLS van fontswaps van typisch 0,05–0,15 naar minder dan 0,01. Dat scheelt enorm.
Strategie 3: Fonts Preloaden
Door kritieke fonts te preloaden geef je de browser een voorsprong bij het downloaden. Combineer dit met een van de bovenstaande strategieën voor het beste resultaat.
<link
rel="preload"
href="/fonts/inter-var.woff2"
as="font"
type="font/woff2"
crossorigin
>Let op het crossorigin attribuut — dit is verplicht voor fonts, zelfs als ze van je eigen domein komen. Zonder dit attribuut wordt het font twee keer gedownload. Ja, echt twee keer. Een veelgemaakte fout.
Advertenties en Embeds: Ruimte Reserveren
Advertenties zijn berucht als CLS-veroorzakers, vooral op mobiel. De oplossing is eenvoudig in concept maar vereist discipline: reserveer altijd ruimte voor advertenties voordat ze laden.
/* Container met vaste minimale afmetingen voor advertenties */
.ad-slot {
min-height: 250px; /* Standaard Medium Rectangle hoogte */
width: 100%;
max-width: 300px;
background-color: #f8f9fa;
display: flex;
align-items: center;
justify-content: center;
contain: layout size;
}
.ad-slot::before {
content: 'Advertentie';
color: #9e9e9e;
font-size: 0.75rem;
}
/* Responsieve advertentie-slot */
.ad-slot--leaderboard {
min-height: 90px;
max-width: 728px;
}
.ad-slot--billboard {
min-height: 250px;
max-width: 970px;
}CSS Containment voor Advertenties
De contain property is een krachtig wapen tegen CLS van dynamische content. Door contain: layout size op een advertentie-container te zetten, vertel je de browser dat niets binnen dit element invloed heeft op de layout buiten het element.
Het resultaat? Verschuivingen binnen de container blijven geïsoleerd. De rest van je pagina merkt er niets van.
.ad-container {
contain: layout size;
min-height: 250px;
width: 300px;
overflow: hidden;
}Dynamische Content Zonder Verschuivingen
Cookie-banners, notificaties, en andere dynamisch geïnjecteerde elementen hoeven geen CLS te veroorzaken — als je ze tenminste correct implementeert.
Overlay in Plaats van Inline
Gebruik position: fixed of position: sticky voor elementen die bovenaan of onderaan de pagina verschijnen. Omdat deze elementen uit de document flow zijn gehaald, veroorzaken ze geen verschuivingen van andere content. Logisch eigenlijk, maar je zou verbaasd zijn hoe vaak dit fout gaat.
/* Cookie-banner zonder CLS */
.cookie-banner {
position: fixed;
bottom: 0;
left: 0;
right: 0;
z-index: 1000;
transform: translateY(100%);
transition: transform 0.3s ease-out;
}
.cookie-banner--visible {
transform: translateY(0);
}Content Altijd Onder Bestaande Content Toevoegen
Wanneer je dynamische content toevoegt, voeg die dan altijd onder de huidige viewport toe in plaats van erboven. Klinkt voor de hand liggend, maar in de praktijk gaat het regelmatig mis.
// Goed: voeg content toe onder bestaande elementen
function voegNotificatieToe(bericht) {
const container = document.querySelector('.notificatie-lijst');
const notificatie = document.createElement('div');
notificatie.className = 'notificatie';
notificatie.textContent = bericht;
container.appendChild(notificatie); // append, niet prepend
}
// Vermijd: content boven bestaande content plaatsen
// container.prepend(notificatie); // Dit veroorzaakt CLS!CSS Animaties: transform in Plaats van Layout Properties
Animaties die layout properties zoals height, width, top of margin wijzigen, triggeren layout-herberekeningen en kunnen CLS veroorzaken. Gebruik in plaats daarvan transform en opacity — deze zijn GPU-versneld en raken de layout niet aan.
/* Slecht: deze animatie veroorzaakt layout shifts */
.accordion-content--open {
height: auto; /* Triggert layout herberekening */
margin-top: 16px;
}
/* Goed: gebruik transform voor visuele effecten */
.accordion-content {
transform: scaleY(0);
transform-origin: top;
transition: transform 0.2s ease-out;
will-change: transform;
}
.accordion-content--open {
transform: scaleY(1);
}Een belangrijk detail: als je een element moet in- of uitklappen en de exacte hoogte niet van tevoren kent, gebruik dan een combinatie van max-height met een overgangswaarde en overflow: hidden. Het is niet perfect CLS-vrij, maar het is een stuk beter dan directe height-transities.
content-visibility: Krachtig maar Gevaarlijk
De CSS property content-visibility: auto kan de renderprestaties drastisch verbeteren door off-screen content niet te renderen totdat deze in beeld komt. Klinkt fantastisch, toch?
Maar hier schuilt een belangrijk CLS-risico: zonder expliciete hoogte behandelt de browser het element als hoogte 0 totdat het in beeld scrollt. En dan springt alles.
De Juiste Combinatie: content-visibility + contain-intrinsic-size
/* Zonder contain-intrinsic-size: CLS-ramp */
.article-section {
content-visibility: auto;
/* Browser behandelt hoogte als 0 wanneer off-screen */
}
/* Met contain-intrinsic-size: stabiele layout */
.article-section {
content-visibility: auto;
contain-intrinsic-size: auto 500px;
/* Browser reserveert 500px en onthoudt de werkelijke hoogte na eerste render */
}Het auto-keyword in contain-intrinsic-size: auto 500px is een slimme toevoeging: de browser onthoudt de werkelijke hoogte nadat het element één keer is gerenderd en gebruikt die opgeslagen waarde bij terugkeren, in plaats van steeds terug te vallen op de initiële schatting. Vooral handig bij back-forward navigatie.
Wanneer Wel en Niet Gebruiken
Gebruik content-visibility: auto voor:
- Lange lijsten met kaarten of artikelen onder de vouw
- Tabbladen of secties die aanvankelijk verborgen zijn
- Footer-content die zelden in beeld komt
Vermijd het voor:
- Content in de initiële viewport (above-the-fold)
- Kleine elementen met minimale renderkosten
- Elementen die je LCP-afbeelding bevatten
CLS Meten en Debuggen: Tooling in 2026
Je kunt niet optimaliseren wat je niet kunt meten. Gelukkig heb je in 2026 uitstekende tools tot je beschikking.
Chrome DevTools: Layout Shift Regions
De snelste manier om layout shifts visueel te identificeren: ga in Chrome DevTools naar Settings → More Tools → Rendering → Layout Shift Regions. Elke layout shift wordt kort paars gemarkeerd, zodat je in één oogopslag kunt zien waar verschuivingen optreden. Dit is meestal mijn eerste stap bij het debuggen van CLS-problemen.
Layout Shift Culprits in het Performance Panel
Chrome DevTools bevat het Layout Shift Culprits-panel in de Performance Insights. Een fantastische tool die je het volgende biedt:
- Real-time visualisatie: layout shifts worden weergegeven terwijl ze plaatsvinden
- Frame-voor-frame weergave: bekijk elke verschuiving stap voor stap
- Automatische identificatie: de tool groepeert de meest verstorende shifts en markeert de veroorzakers
- Visuele overlays: problematische elementen worden gemarkeerd op de pagina
CLS Meten met de Layout Instability API
Voor programmatische CLS-monitoring in productie kun je de Layout Instability API gebruiken via de PerformanceObserver. Dit is wat ik aanraad voor teams die serieus met webprestaties bezig zijn:
// CLS meten en naar analytics sturen
let clsWaarde = 0;
let clsSessieEntries = [];
let clsSessieWaarde = 0;
let maxClsWaarde = 0;
const observer = new PerformanceObserver((entryList) => {
for (const entry of entryList.getEntries()) {
// Negeer shifts na gebruikersinteractie
if (entry.hadRecentInput) continue;
// Log de veroorzakende elementen
if (entry.sources) {
for (const { node, currentRect, previousRect } of entry.sources) {
console.log('Layout shift bron:', node, {
van: previousRect,
naar: currentRect,
score: entry.value
});
}
}
// Session window berekening
const laatsteEntry = clsSessieEntries[clsSessieEntries.length - 1];
if (laatsteEntry &&
entry.startTime - laatsteEntry.startTime < 1000 &&
entry.startTime - clsSessieEntries[0].startTime < 5000) {
clsSessieWaarde += entry.value;
clsSessieEntries.push(entry);
} else {
clsSessieWaarde = entry.value;
clsSessieEntries = [entry];
}
if (clsSessieWaarde > maxClsWaarde) {
maxClsWaarde = clsSessieWaarde;
}
}
});
observer.observe({ type: 'layout-shift', buffered: true });
// Verstuur de score wanneer de pagina wordt verlaten
document.addEventListener('visibilitychange', () => {
if (document.visibilityState === 'hidden') {
observer.takeRecords();
console.log('Definitieve CLS:', maxClsWaarde);
// navigator.sendBeacon('/analytics', JSON.stringify({ cls: maxClsWaarde }));
}
});De web-vitals Bibliotheek
Wil je het jezelf makkelijker maken? De web-vitals bibliotheek is de gouden standaard en doet al het zware werk voor je:
<script type="module">
import { onCLS } from 'https://unpkg.com/web-vitals@4?module';
onCLS((metric) => {
console.log('CLS:', metric.value);
console.log('Entries:', metric.entries);
// Verstuur naar je analytics platform
fetch('/api/vitals', {
method: 'POST',
body: JSON.stringify({
name: metric.name,
value: metric.value,
id: metric.id,
navigationType: metric.navigationType
}),
keepalive: true
});
});
</script>Velddata vs. Labdata
Dit is misschien wel het belangrijkste punt van dit hele artikel: lab-tools zoals Lighthouse meten CLS alleen tijdens de initiële paginalaadbeurt. Echte gebruikers scrollen, klikken, en blijven langer op de pagina — en ervaren daardoor verschuivingen die labtools volledig missen.
Gebruik daarom altijd velddata uit het Chrome User Experience Report (CrUX), Google Search Console, of je eigen Real User Monitoring (RUM) als primaire informatiebron. Labdata is handig voor debuggen, maar velddata vertelt je wat er echt gebeurt.
Een Praktische CLS-checklist
Gebruik deze checklist bij elk project om CLS systematisch aan te pakken. Ik print 'm zelf altijd uit en hang 'm naast m'n scherm (oké, niet echt — maar ik heb 'm wel als bookmark):
- Afbeeldingen en video: controleer of alle
<img>en<video>elementenwidthenheightattributen hebben - CSS aspect-ratio: gebruik
aspect-ratiovoor responsieve media-containers en skeleton screens - Webfonts: implementeer
font-display: optionalofswapmetsize-adjustfallbacks - Font preloading: preload kritieke fonts met
<link rel="preload"> - Advertenties: reserveer ruimte met
min-heightencontain: layout size - Dynamische content: gebruik
position: fixedvoor banners, voeg content altijd onder bestaande content toe - Animaties: gebruik alleen
transformenopacityvoor animaties - content-visibility: combineer altijd met
contain-intrinsic-size - Third-party scripts: laad niet-kritieke scripts met
asyncofdefer - bfcache: zorg dat je pagina's in aanmerking komen voor de back-forward cache
bfcache: Het Verborgen CLS-wapen
Een techniek die veel ontwikkelaars over het hoofd zien: zorg dat je pagina's in aanmerking komen voor de back-forward cache (bfcache). Wanneer een gebruiker op de terugknop drukt, herstelt de browser de pagina exact zoals die was — volledig geladen, geen verschuivingen. Nul CLS. Het is eigenlijk te mooi om waar te zijn, maar het werkt echt.
Veelvoorkomende bfcache-blokkeerders die je moet vermijden:
unloadevent listeners (gebruikpagehidein plaats daarvan)Cache-Control: no-storeheaders op de hoofdpagina- Openstaande
IndexedDB-verbindingen die niet worden gesloten
Veelgestelde Vragen over CLS
Wat is een goede CLS-score en waarom is 0,1 de drempel?
Google beschouwt een CLS-score van 0,1 of lager als "goed". Deze drempel is gebaseerd op uitgebreid onderzoek naar gebruikerservaring. Uit studies blijkt dat verschuivingen boven 0,1 merkbaar worden voor gebruikers en leiden tot hogere bouncerates en lagere tevredenheidsscores. De meting vindt plaats op het 75e percentiel, wat betekent dat 75% van alle paginalaadmomenten onder deze drempel moet vallen.
Telt een layout shift die door een gebruikersklik wordt veroorzaakt mee voor CLS?
Nee, gelukkig niet. Layout shifts die plaatsvinden binnen 500 milliseconden na een gebruikersinteractie (klik, tik, of toetsaanslag) worden door de browser gemarkeerd met hadRecentInput: true en tellen niet mee voor de CLS-score. Dit geldt voor alle directe interacties, maar niet voor hover of scroll — die worden niet als "input" beschouwd.
Waarom verschilt mijn CLS in Lighthouse van de CLS in Google Search Console?
Lighthouse meet CLS alleen tijdens de initiële paginalaadbeurt in een gesimuleerde omgeving (labdata). Google Search Console toont velddata van echte gebruikers via het Chrome User Experience Report (CrUX), gemeten over de volledige levenscyclus van de pagina. Echte gebruikers scrollen, interacteren, en blijven langer op de pagina, waardoor ze verschuivingen ervaren die Lighthouse nooit ziet. Velddata is altijd de primaire maatstaf — onthoud dat.
Kan content-visibility mijn CLS-score verslechteren?
Ja, absoluut — als je het verkeerd implementeert. De CSS property content-visibility: auto behandelt off-screen elementen standaard als hoogte 0. Wanneer een gebruiker naar zo'n element scrollt, krijgt het plotseling zijn werkelijke hoogte en verschuift alles eronder. De oplossing is simpel: voeg altijd contain-intrinsic-size toe met een realistische schatting van de hoogte.
Hoe voorkom ik CLS door webfonts zonder mijn merkfont op te geven?
Gebruik font-display: swap in combinatie met size-adjust, ascent-override en descent-override op een fallback @font-face declaratie. Hiermee stem je de afmetingen van het systeemfont af op je webfont, zodat de fontwissel vrijwel onzichtbaar wordt. Tools zoals Fontaine en next/font berekenen de juiste waarden automatisch. Combineer dit met het preloaden van je kritieke fontbestanden voor het beste resultaat.