De beste tips om CLS-problemen in Search Console op te lossen

Table of contents

CLS: De achtergrond

Cumulative Layout Shift meet onverwachte layoutbewegingen. Elke keer dat een zichtbaar element van positie verschuift terwijl een pagina laadt of wordt gebruikt, wordt een layout-shift-score berekend. De cumulatieve score is CLS.

Veelvoorkomende oorzaken:

• Afbeeldingen of iframes zonder expliciete width- en height-attributen
• Advertenties die uitbreiden nadat de omringende content al is gerenderd
• Dynamisch ingevoegde content (banners, cookiemeldingen, chatwidgets) die boven bestaande content wordt geplaatst
• Webfonts die een flits en reflow veroorzaken bij het laden (FOUT/FOIT)
• JavaScript van derden dat UI-elementen toevoegt na de initiële render

Gerelateerd: Hoe LCP-problemen in Search Console op te lossen

CLS meten

Google Search Console

Het Core Web Vitals-rapport van Search Console is het startpunt. Het toont pagina’s die zijn gemarkeerd als ‘Slecht’ (CLS ≥ 0,25) of ‘Moet verbeteren’ (0,1–0,25), gegroepeerd op probleemtype. Gebruik dit rapport om de lijst van getroffen URL’s te krijgen.

PageSpeed Insights

PageSpeed Insights (PSI) toont zowel laboratoriumdata (Lighthouse-simulatie) als velddata van echte gebruikers via het Chrome UX Report (CrUX). De velddata telt zwaarder voor rankingdoeleinden — het weerspiegelt echte gebruikerservaringen, niet alleen een synthetische test.

PSI simuleert alleen het initiële viewport bij het laden, waardoor het CLS dat wordt geactiveerd door scrollen of gebruikersinteractie kan missen. Gebruik voor die gevallen Chrome DevTools.

Chrome DevTools en de Web Vitals-extensie

De Web Vitals Chrome-extensie (onderhouden door Google) toont live CLS-scores terwijl je scrollt en met een pagina interageert. Dit is de snelste manier om layoutverschuivingen handmatig te reproduceren. Het Performance-paneel van Chrome DevTools markeert ook layout-shift-records met annotaties die tonen welke elementen zijn verschoven en hoeveel.

CLS-problemen oplossen

Width en height toevoegen aan alle afbeeldingen en iframes

Dit is de meest impactvolle oplossing voor de meeste sites. Zonder expliciete afmetingen weet de browser niet hoeveel ruimte hij moet reserveren terwijl een afbeelding laadt, waardoor de content eronder naar beneden wordt geduwd wanneer de afbeelding verschijnt.

<!-- Slecht: geen afmetingen -->
<img src="photo.jpg" alt="…">

<!-- Goed: expliciete afmetingen laten de browser ruimte reserveren -->
<img src="photo.jpg" alt="…" width="800" height="450">

Moderne CSS (aspect-ratio) bereikt hetzelfde effect voor responsieve afbeeldingen, maar het expliciet instellen van width- en height-attributen in HTML is de meest betrouwbare aanpak en wordt automatisch verwerkt door de meeste moderne frameworks en CMS-afbeeldingspipelines.

Ruimte reserveren voor advertenties

Advertenties zijn de meest voorkomende oorzaak van hoge CLS op gemonetariseerde sites. Advertentienetwerken leveren dynamische formaten en als er geen ruimte is gereserveerd, herstroomt de pagina wanneer de advertentie laadt.

1. Reserveer een vaste container (min-height overeenkomend met je meest voorkomende advertentiegrootte) voordat de advertentietag laadt.
2. Verklein de container niet als er geen advertentie wordt getoond — een leeg tijdelijk plaatshouder voorkomt een tweede reflow.
3. Wees extra voorzichtig met advertenties die vlakbij de bovenkant van het viewport zijn geplaatst. Niet-sticky advertenties die boven de vouw worden ingevoegd, veroorzaken de slechtste CLS-scores.
4. Gebruik historische impressiedata van je advertentienetwerk om te bepalen welke advertentieformaten het meest voorkomen voor elke positie, en dimensioneer de container dienovereenkomstig.

Het invoegen van content boven bestaande content vermijden

Cookietoestemmingsbanner, meldingsprompts en chatwidgets die asynchroon laden en boven bestaande content verschijnen, zijn een frequente CLS-bron. Opties:

• Laad ze in een overlay met vaste positie (ze beïnvloeden de documentstroom niet).
• Wijs vooraf ruimte toe in de layout als ze inline moeten verschijnen.
• Overweeg voor cookiebanner specifiek een plaatsing onderaan het scherm — dit vermijdt CLS volledig en is even compliant.

Webfont-laden herstellen (FOIT en FOUT)

FOIT (Flash of Invisible Text) treedt op wanneer een browser tekst verbergt totdat een aangepast lettertype laadt. FOUT (Flash of Unstyled Text) treedt op wanneer een fallback-lettertype eerst wordt getoond en vervolgens wordt omgewisseld — het verschil in lettertypemetrieken veroorzaakt een layoutverschuiving.

De oplossing is font-display: swap gecombineerd met <link rel="preload"> voor kritieke lettertypen:

<link rel="preload" href="/fonts/my-font.woff2" as="font" type="font/woff2" crossorigin>

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

font-display: swap veroorzaakt FOUT (zichtbare maar ongestijlde tekst) in plaats van FOIT (onzichtbare tekst), wat beter is voor CLS omdat de tekst onmiddellijk zichtbaar is. Om de metrische impact van de wissel verder te verminderen, gebruik de CSS-eigenschap size-adjust om fallback-lettertypemetrieken te laten overeenkomen met het aangepaste lettertype — dit minimaliseert de reflow wanneer het aangepaste lettertype van kracht wordt.

JavaScript van derden

Scripts van derden (deelknoppen, commentaarwidgets, live chat, analytics-popups) laden asynchroon en injecteren vaak UI-elementen nadat de pagina al is gerenderd. Om hun CLS-impact te minimaliseren:

• Duw visuele elementen van derden indien mogelijk onder het initiële viewport — content lager op de pagina heeft meer tijd om te laden voordat de gebruiker het bereikt.
• Definieer containerdimensies vooraf voordat het script wordt uitgevoerd, zodat de browser al weet hoeveel ruimte hij moet reserveren.
• Gebruik het Network-tabblad van Chrome DevTools gefilterd op origins van derden om te identificeren welke scripts bijdragen aan layoutverschuivingen.

Lazy loading en tijdelijke aanduidingen

Lazy loading stelt het laden van afbeeldingen uit totdat een afbeelding dicht bij het viewport is, wat bandbreedte bespaart. Maar als er geen tijdelijke aanduiding is ingesteld, klapt de afbeeldingscontainer in tot nul hoogte en springt dan open wanneer de afbeelding laadt.

Zorg er altijd voor dat lazy-geladen elementen expliciete afmetingen of via CSS ingesteld aspect-ratio hebben, zodat de browser de juiste ruimte reserveert zelfs voordat de afbeelding laadt. Dit geldt zowel voor het native loading="lazy" als voor op JavaScript gebaseerde lazy loaders.

CLS — FAQ 2026

Is FID nog steeds een rankingsignaal in 2026?

Nee. Google heeft FID (First Input Delay) in maart 2024 officieel als Core Web Vital uitgefaseerd en vervangen door INP (Interaction to Next Paint). Het huidige CWV-trio is LCP, INP en CLS. Werk alle interne documentatie of tools bij die nog naar FID verwijzen.

Wat is een goede CLS-score om na te streven?

Google’s drempelwaarden: onder 0,1 is ‘goed’, 0,1–0,25 is ‘moet verbeteren’, boven 0,25 is ‘slecht’. Streef naar onder 0,1. De score wordt gemeten op het 75e percentiel van paginaladingen in CrUX-velddata.

Beïnvloedt CLS rankings?

Ja, maar het is één signaal onder velen. Core Web Vitals zijn sinds medio 2021 een paginaervarings-rankingfactor. Een slechte CLS zal een sterke pagina niet kelderen, maar het kan een tiebreaker zijn en zal op eigen merites direct de gebruikersbetrokkenheidsmetrieken (bouncepercentage, sessiediepte) schaden.

Mijn PSI-score toont goede CLS maar Search Console markeert de pagina als slecht — welke heeft gelijk?

Vertrouw Search Console (velddata) boven PSI-laboratoriumdata wanneer ze conflicteren. PSI-laboratoriumtests simuleren alleen het initiële viewport-laden; het mist CLS die wordt geactiveerd door gebruikersscrolling, lettertypeswaps op tragere verbindingen of advertenties die na interactie worden geladen. De CrUX-velddata in Search Console weerspiegelt echte gebruikers in echte omstandigheden.

Gerelateerde lectuur:

• Hoe LCP-problemen in Search Console op te lossen
• Hoe de snelheid van je website te optimaliseren
• Technische SEO-audit

De kortere versie

Als je dit leest omdat de workflow die het beschrijft je week opeet, is dat precies het soort lus waarvoor ik AI-agenten bouw. Twee bouwslots tegelijk open.

Bijgewerkt voor mei 2026

Het Google-verhaal van 2026 is AI Overviews overal: het SGE-experiment van 2023 groeide uit tot een standaardfunctie in mei 2024 en verschijnt nu op naar schatting ~60% van de informatieve US-zoekopdrachten. Voor SEO- en advertentie-operators:

• Organische CTR op zoekopdrachten met AI Overviews is gemiddeld met 15–30% gedaald op basis van gepubliceerde studies van Ahrefs, Authoritas en vergelijkbare bronnen (data 2024–25).
• Google Ads hernoemde verschillende PMax-functies als AI-powered Search; de campagnebeheer-UI stelt nu standaard AI-biedstrategieën voor.
• Search Console voegde eind 2025 een filter voor ‘AI Overview-impressies’ toe — als een artikel hier verwijst naar GSC-rapportage, heeft het draaiboek een update nodig.
• Google’s advertentie-inkomsten overschreden ~$265 miljard in 2024; Search blijft ~57% van de totale Alphabet-inkomsten.

Het antwoord op “hoe verdient Google geld” in 2026: nog steeds Search-advertenties (dominant), maar YouTube Ads, Cloud en Abonnementen (YouTube Premium + Google One) zijn nu allemaal wezenlijke inkomstenlijnen.