Wat is CLS en waarom telt het?
CLS staat voor Cumulative Layout Shift, oftewel cumulatieve indelingsverschuiving. Het meet hoeveel de zichtbare inhoud van je pagina onverwacht verspringt terwijl die laadt. Je kent het gevoel: je wilt op een knop klikken, er laadt nog een afbeelding in, alles schuift naar beneden, en je klikt op de verkeerde plek.
CLS is een van de drie Core Web Vitals waarmee Google de gebruikerservaring meet, naast LCP en INP. Google wil een CLS-score onder de 0,1. Tussen 0,1 en 0,25 is matig, daarboven slecht.
Waarom het telt: verspringende pagina's zijn irritant en kosten conversie. En omdat CLS een rankingsignaal is, kan een slechte score je ook zichtbaarheid kosten. Het goede nieuws: CLS is vaak een van de makkelijkst op te lossen vitals.
Hoe wordt CLS berekend?
CLS is geen tijd maar een score zonder eenheid, opgebouwd uit twee factoren: hoeveel van het scherm verschuift (impact fraction) en hoe ver het verschuift (distance fraction). Een klein element dat een klein stukje verspringt levert een lage score, een groot blok dat ver wegschuift een hoge.
Belangrijk: alleen onverwachte verschuivingen tellen mee. Een verschuiving die direct volgt op een klik van de gebruiker, bijvoorbeeld een uitklappend menu, telt niet mee. Google gaat ervan uit dat je die zelf hebt uitgelokt en dus verwacht.
Je meet CLS met PageSpeed Insights of de Chrome DevTools. PageSpeed toont zowel labdata (een enkele test) als velddata (echte bezoekers). De velddata onder "Core Web Vitals-beoordeling" is wat Google voor ranking gebruikt.
De grote oorzaken van layout shift
Bijna alle CLS-problemen komen van elementen die ruimte innemen nadat de pagina al zichtbaar is. Dit zijn de meest voorkomende schuldigen.
- Afbeeldingen zonder afmetingen: zonder width en height weet de browser niet hoeveel ruimte te reserveren, dus schuift alles als de afbeelding laadt.
- Advertenties en embeds: banners, YouTube-video's en social embeds die pas later laden en dan ruimte opeisen.
- Web fonts die laat laden: tekst verschijnt eerst in een systeemfont en springt bij het inladen van je eigen lettertype (FOUT/FOIT).
- Dynamisch ingevoegde content: cookiebanners, notificaties of AJAX-content die boven bestaande inhoud verschijnt.
- Iframes zonder vaste hoogte: kaarten, formulieren en widgets die hun eigen hoogte bepalen na het laden.
De fixes: reserveer de ruimte
De rode draad van elke CLS-fix is hetzelfde principe: reserveer vooraf de ruimte die een element straks inneemt, zodat er niets hoeft te verschuiven als het laadt.
Geef afbeeldingen altijd afmetingen
Zet width en height als attributen op elke img, of gebruik een aspect-ratio in CSS. De browser reserveert dan de juiste ruimte voordat de afbeelding er is. Dit lost verreweg de meeste shifts op. Combineer het met lazy loading en WebP.
Reserveer ruimte voor advertenties en embeds
Geef advertentieplekken en video-embeds een vaste minimale hoogte via CSS, zodat de ruimte er al is voordat de inhoud laadt.
Laad fonts slim
Gebruik font-display: optional of swap met een goed gekozen fallback-font van vergelijkbare afmeting, en preload je belangrijkste lettertype. Zo blijft de sprong bij het wisselen minimaal.
Voeg dynamische content onder bestaande toe
Plaats cookiebanners en notificaties zo dat ze bestaande content niet naar beneden duwen, bijvoorbeeld als overlay of onderaan, niet ingevoegd bovenaan.
CLS op WordPress specifiek
Op WordPress zit CLS vaak in een paar herkenbare plekken. Thema's die afbeeldingen zonder afmetingen uitserveren, sliders bovenaan, en plugins die na het laden iets injecteren. Loop deze na voordat je diep in de code duikt.
Een caching- en optimalisatieplugin helpt, mits goed ingesteld. Bij LiteSpeed Cache kun je bijvoorbeeld het inladen van fonts en CSS sturen. Maar let op: agressieve optimalisatie zoals het uitstellen van CSS kan CLS juist verergeren als het niet zorgvuldig gebeurt. Test na elke wijziging.
Onze ervaring vanuit het bouwen van MKB-sites: de meeste WordPress-CLS is opgelost door afbeeldingsafmetingen te forceren en de fontlading te fatsoeneren. Pas als dat op orde is, ga je naar de fijnere afstelling. Snelle hosting helpt indirect: hoe eerder assets binnen zijn, hoe minder laat-schuivende elementen.
Praktijkvoorbeeld: een homepage stabiliseren
Neem een MKB-homepage met een CLS van 0,32, ruim in de rode zone. In PageSpeed Insights zie je onder "Vermijd grote indelingsverschuivingen" welke elementen schuiven. In dit geval: de hero-afbeelding, een reviews-widget en het lettertype.
Fix 1: hero-afbeelding krijgt expliciete width en height plus aspect-ratio in CSS. Winst: de grootste sprong verdwijnt, CLS zakt naar circa 0,18.
Fix 2: de reviews-widget krijgt een vaste min-height van de ruimte die hij normaal inneemt. CLS zakt naar circa 0,09.
Fix 3: het custom font wordt gepreload met een passende fallback. De laatste kleine sprong verdwijnt, CLS eindigt rond 0,04.
Totale werktijd: 2 tot 4 uur voor iemand die de weg kent in het thema. Resultaat: van rood (0,32) naar groen (0,04), ruim onder de norm van 0,1. Geen enkele nieuwe functie nodig, puur ruimte reserveren.
Meten en volhouden
CLS is geen eenmalige klus. Elke nieuwe plugin, banner of embed kan de score weer verpesten. Neem het op in je routine: check je Core Web Vitals maandelijks in Search Console onder het kopje Ervaring, en test grote wijzigingen vooraf in PageSpeed Insights.
Let op het verschil tussen lab- en velddata. Een enkele labtest kan groen zijn terwijl echte bezoekers op tragere apparaten meer shift ervaren. De velddata over 28 dagen is de waarheid voor Google. Verbeteringen zijn daar pas na enkele weken zichtbaar.
De houding die werkt: behandel CLS als hygiëne, niet als project. Wie bij elke nieuwe afbeelding netjes de afmetingen meegeeft en bij elke embed ruimte reserveert, houdt de score vanzelf groen. Twijfel je waar je site staat? Onze scan meet het mee.