Wat is Cumulative Layout Shift (CLS) en hoe los je het op

Wat is Cumulative Layout Shift (CLS)?

Cumulative Layout Shift (CLS) vertegenwoordigt het onderdeel "visuele stabiliteit" binnen de Core Web Vitals. CLS meet hoe de pagina beweegt terwijl content rendert of er nieuwe content verschijnt. Je merkt het als je de draad kwijtraakt in een artikel dat je aan het lezen bent, of als je op de verkeerde knop klikt doordat die onder je vinger verschoof. Soms noemen mensen het "content layout shift", maar de metric heet voluit Cumulative Layout Shift.

Wat is een goede Cumulative Layout Shift (CLS)-score?

Een goede CLS-score ligt tussen 0 en 0,1. Tussen 0,1 en 0,25 heeft de score verbetering nodig, en elke CLS-score boven 0,25 geldt als slecht. Om te slagen voor de Core Web Vitals op Cumulative Layout Shift heeft minstens 75% van je paginabezoeken een "goede" CLS-score nodig. Dat is de p75 van je field data, waarbij mobiel en desktop apart worden gemeten. CLS heeft geen eenheid: het is een score, waar LCP en INP tijden zijn.

Het Core Web Vitals-rapport in Google Search Console groepeert falende URL's per probleem. "CLS issue: more than 0.1 (mobile)" betekent verbetering nodig, "CLS issue: more than 0.25 (desktop)" betekent slecht, en beide drempelwaarden bestaan voor elk apparaat. Search Console middelt je field data over een voortschrijdend venster. Zet je een fix live, dan kleurt het rapport dus niet meteen dezelfde dag groen: wekenlang toont het deels nog de oude site.

Wat een layout shift je kost

Een pagina die alle kanten op springt voelt kapot, zelfs als alles erop werkt.

• Bezoekers en je merk: Een shift onderbreekt waar de bezoeker mee bezig was. Ze raken de regel kwijt die ze lazen of tikken op de verkeerde link, en een deel haakt af en vertrekt. Een site die blijft bewegen oogt ook slecht gebouwd, en dat straalt af op het bedrijf erachter.
• Toegankelijkheid: Layout shifts komen het hardst aan als je maar een deel van de pagina ziet, bijvoorbeeld bij inzoomen of het gebruik van een schermloep. Eén shift kan de tekst die je las al uit beeld duwen.
• SEO en zoekranking: Google's rankingsystemen gebruiken de Core Web Vitals, en CLS is er daar een van. Het is een kleine factor. Google zegt dat het de meest relevante content eerst toont. Een goede page experience helpt als pagina's ongeveer even relevant zijn.

Hoe wordt CLS gemeten?

Browsers rapporteren layout shifts via de Layout Instability API. Plak dit in de console en elke shift wordt gelogd:

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    console.log('Layout shift:', entry);
  }
}).observe({type: 'layout-shift', buffered: true});

Elke entry heeft een value, de score van die shift, en een sources-lijst met de verschoven elementen. Bij shifts vlak na een klik staat hadRecentInput op true. Die worden hier wel gelogd, maar tellen niet mee voor CLS.

De CLS berekenen

Elke layout shift krijgt een eigen score:

layout shift score = impact fraction * distance fraction

De impact fraction is hoeveel van de viewport de bewegende elementen raken, geteld vanaf waar ze voor de shift stonden tot waar ze zijn geëindigd. De distance fraction is hoe ver ze zijn verschoven, als deel van de grootste afmeting van de viewport (op een telefoon is dat de hoogte).

Neem een element dat de helft van de viewport beslaat en met 25% van de viewporthoogte naar beneden verschuift. Voor en na de verschuiving beslaat het samen 75% van de viewport. Dat levert een impact fraction van 0,75 op en een distance fraction van 0,25. Die shift scoort dus 0,75 * 0,25 = 0,1875. Eén zo'n shift zit op zichzelf al boven de 0,1. De CLS van de pagina telt deze shift-scores per sessievenster bij elkaar op, zoals hieronder uitgelegd.

Verwachte versus onverwachte layout shifts

Klik je op een link om meer items te laden, dan verwacht je dat er nieuwe items verschijnen en dat de pagina beweegt. Juist daarom tellen alleen onverwachte layout shifts mee voor CLS. Elke shift binnen 500 milliseconden na een klik, tik of toetsaanslag blijft buiten de berekening. Een dropdownmenu dat opent na een klik kost je dus niets. Scrollen telt niet als input, daarover hieronder meer.

Layout shift-sessies

Toen CLS net werd geïntroduceerd, telde het elke shift over de hele levensduur van de pagina bij elkaar op. Pagina's die lang openstaan, zoals infinite scrollers en single-page apps, bleven maar score opbouwen. Sinds juni 2021 wordt CLS berekend in sessies. Elke sessie duurt maximaal 5 seconden en stopt zodra er een pauze van 1 seconde tussen layout shifts valt. De sessie met de hoogste CLS-score wordt de definitieve CLS-score.

Stel: de eerste sessie telt op tot 0,095, de volgende tot 0,15 en de laatste tot 0. De uiteindelijke CLS-score is de hoogste van de drie: 0,15.

Veelvoorkomende oorzaken van CLS

Elke layout shift werkt hetzelfde. Nadat de pagina gerenderd is, wordt een element groter of kleiner, of verandert het van positie. Alles wat erna in de layout staat, verschuift mee. Dit zijn de gebruikelijke oorzaken:

Afbeeldingen, video's en iframes zonder afmetingen

Media zonder afmetingen is een van de meest voorkomende oorzaken van CLS. De browser weet pas hoe groot een afbeelding is zodra de eerste bytes van het bestand binnenkomen. Tot die tijd reserveert de browser zonder width en height (of een CSS-aspect-ratio) geen ruimte en heeft de afbeelding geen hoogte. Laadt de afbeelding in, dan schuift alles eronder naar beneden.

Hoe afbeeldingen en media layout shifts veroorzaken behandelt afbeeldingen, video's en iframes zonder afmetingen, de CSS-valkuil van width: auto, art direction, mismatches bij responsive afbeeldingen, lazy loading en placeholders.

Web font-swaps

Terwijl het web font downloadt, rendert de pagina de tekst in een fallback-font. Zodra het web font binnenkomt, reflowt de tekst. Verschillende letterbreedtes en regelhoogtes zorgen voor andere regelovergangen, waardoor elk blok onder die alinea verschuift.

De Lighthouse-audit "Ensure text remains visible during webfont load" stuurt je richting font-display: swap. Voor CLS lost dat op zichzelf niets op: de tekst verschijnt weliswaar sneller in het fallback-font, maar de swap verschuift de boel alsnog. Wat het echt oplost, is een fallback die precies dezelfde ruimte inneemt, met @font-face metric overrides zoals size-adjust en ascent-override. Lever het font daarnaast sneller uit door het zelf te hosten en kritieke fonts te preloaden. In de handleiding voor opsporen en oplossen vind je de code.

CSS-animaties en -transitions

Animeer je top, left, width of height, dan berekent de browser de layout bij elk frame opnieuw. Elk van die frames kan een layout shift zijn. transform en opacity triggeren nooit layout, dus verplaats elementen daarmee. Layout shifts door CSS-transitions oplossen legt de fix stap voor stap uit.

Advertenties, embeds en dynamisch geïnjecteerde content

Advertenties laden laat en drukken content omlaag. Een cookiebanner die over de pagina heen ligt verschuift niets, maar een banner die bovenaan wordt ingevoegd drukt de hele pagina naar beneden. AJAX-requests doen hetzelfde als ze content injecteren zonder ruimte te reserveren. In al die gevallen verschijnt er iets op de pagina waar de browser tijdens het berekenen van de layout nog niets van wist. Reserveer die ruimte vooraf, bijvoorbeeld met min-height op de container. Voor third-party embeds zoals YouTube en Google Maps neemt het facade pattern de CLS zelfs helemaal weg.

Layout shifts getriggerd door scrollen

Een Lighthouse-laadtest scrolt niet en mist deze CLS-oorzaak dus. Headers die inklappen bij het scrollen, parallax-effecten en krimpend navigatiemenu's animeren vaak top of height. In de specificatie van de Layout Instability API telt scrollen niet als interactie die shifts uitsluit. Elke layout shift die erdoor getriggerd wordt, telt dus mee voor je CLS-score. Gebruik transform: translateY() voor alles wat beweegt tijdens het scrollen. Hoe scroll-animaties CLS veroorzaken bevat de details.

CLS-problemen opsporen en oplossen

Begin bij field data. Een labtest ziet alleen de eerste seconden van het laden van de pagina, terwijl je bezoekers scrollen, wachten op advertenties en doorlezen. Controleer de p75 CLS voor mobiel en desktop apart: bij CLS scoort desktop vaak slechter dan mobiel. Google Search Console laat zien welke groepen pagina's zakken. Een RUM-tool zoals CoreDash legt daarnaast vast welk element precies verschoof. Zo zie je meteen of het de productafbeelding op het ene template is of het advertentieblok op het andere. Kijk ook naar de trend. Een plotselinge sprong betekent meestal dat een release iets heeft toegevoegd, zoals een nieuwe banner of een advertentieblok.

Reproduceer het probleem vervolgens in Chrome DevTools of met de extensie Core Web Vitals Visualizer om te ontdekken wat de beweging veroorzaakt. De stapsgewijze diagnose, tool-walkthroughs, code-fixes voor elke oorzaak en een checklist voor snelle fixes vind je in Cumulative Layout Shift (CLS)-problemen opsporen en oplossen.

Case study: de Core Web Vitals A/B-test van Rakuten 24

Rakuten 24, een Japanse webwinkel, optimaliseerde een drukbezochte landingspagina voor de Core Web Vitals. Ze draaiden deze een maand lang tegen het origineel, waarbij beide versies 50% van het verkeer kregen. Voor CLS reserveerden ze ruimte voor afbeeldingen met CSS-aspect-ratio en voor lazy-loaded elementen met min-height. De CLS van de geoptimaliseerde pagina lag 92,72% lager. In hun mobiele laadtest was de pagina bovendien 0,4 seconden eerder klaar met laden, met een betere FCP en TTFB. Vergeleken met het origineel leverde de geoptimaliseerde pagina het volgende op:

• 53,37% meer omzet per bezoeker
• 33,13% hogere conversie
• 15,20% hogere gemiddelde bestelwaarde
• 35,12% lager uitstappercentage

CLS liet de grootste verbetering zien in de test, maar ook de laadtijd, FCP en TTFB gingen vooruit. Deze resultaten zijn dus te danken aan de totale optimalisatie. Haal ze niet aan als bewijs voor wat CLS alleen waard is.

Wat CLS-data uit de praktijk laat zien

In het Chrome UX Report van augustus 2026 had 81,5% van de origins een goede CLS, vergeleken met 80,1% in augustus 2025.

Op corewebvitals.io zelf meet CoreDash dat CLS de best presterende Core Web Vital is. Van alle page loads scoort 92,8% "goed", met nauwelijks verschil tussen desktop (92,8% goed) en mobiel (92,7% goed). Beide hebben een p75 van 0: bij minstens driekwart van de page loads trad er dus helemaal geen layout shift op.

Over het hele web gezien is CLS beter op mobiel dan op desktop. Dat is het omgekeerde van LCP en INP. De 2025 Web Almanac toont de cijfers, inclusief hoe vaak pagina's de hierboven genoemde oorzaken bevatten:

• 81% van de mobiele sites en 72% van de desktopsites heeft een goede CLS. Ongeveer 9% van de mobiele sites en 10% van de desktopsites scoort slecht.
• 62% van de mobiele pagina's heeft minstens één afbeelding zonder expliciete afmetingen, tegenover 66% in 2024.
• 40% van de mobiele pagina's (44% op desktop) bevat non-composited animaties.
• 87% van de mobiele pagina's gebruikt minstens één web font, en ongeveer 12% preloadt er een (Fonts-hoofdstuk).

Gerelateerde handleidingen

Deze handleidingen gaan dieper in op het opsporen en oplossen van CLS:

• CLS-problemen opsporen en oplossen: stapsgewijze diagnose met tool-walkthroughs, code-fixes voor elke oorzaak en een checklist voor snelle fixes.
• Hoe afbeeldingen en media layout shifts veroorzaken: CLS door afbeeldingen, video's en iframes zonder afmetingen, art direction, responsive afbeeldingen, lazy loading en placeholders.
• Layout shifts door automatisch schalende afbeeldingen oplossen: geef afbeeldingen en responsive containers de juiste afmetingen mee.
• Layout shifts door CSS-transitions oplossen: spoor CSS-animaties op die layout triggeren en vervang ze door composited alternatieven.
• Door scrollen getriggerde animaties en CLS: de CLS-oorzaak die een Lighthouse-laadtest mist, en hoe je die fixt.
• Google Fonts zelf hosten: minder CLS bij het laden van fonts door ze zelf te hosten met de juiste font-display en preloading.
• Zorg dat tekst zichtbaar blijft tijdens het laden van web fonts: font-display en font metric overrides tegen layout shifts door font-swaps.
• Bouw een chatwidget met perfecte Core Web Vitals: een case study over het toevoegen van een third-party widget zonder regressies op CLS, INP of LCP.

Het Core Web Vitals-overzicht behandelt alle drie de metrics, en de Core Web Vitals-checklist helpt je bij de audit van je site.