Core Web Vitals uitgelegd: LCP, CLS en INP

Core Web Vitals zijn drie cijfers waarmee Google meet hoe prettig je website laadt: Largest Contentful Paint (LCP) voor laadsnelheid, Interaction to Next Paint (INP) voor hoe snel je site reageert, en Cumulative Layout Shift (CLS) voor hoe stil de pagina blijft staan. Goed is een LCP van maximaal 2,5 seconden, een INP van maximaal 200 milliseconden en een CLS van maximaal 0,1.

De grenswaarden op een rij

Google deelt elk cijfer in drie groepen in. Dit zijn de waarden zoals web.dev ze noemt:

Belangrijk detail: Google kijkt niet naar het gemiddelde, maar naar het 75e percentiel. Driekwart van de bezoeken moet dus binnen de grens vallen, apart gemeten voor mobiel en desktop. Een paar trage bezoekers op een slechte verbinding maken je score niet meteen rood, maar een site die alleen op snelle wifi goed is, haalt het ook niet.

Largest contentful paint: wanneer is de pagina er?

LCP meet hoe lang het duurt voordat het grootste element in beeld staat. Meestal is dat de grote foto bovenaan, een video of het grootste tekstblok. Voor een bezoeker is dat het moment waarop de pagina ‘er is’.

Een slechte LCP heeft bijna altijd een van deze oorzaken:

• Een te zware headerfoto, of een foto in een oud formaat. Lees hoe je dat oplost in het artikel over afbeeldingen comprimeren.

• Een server die traag antwoordt, door ontbrekende caching of te lichte hosting.

• Lazy loading op de bovenste afbeelding. Uitgesteld laden is goed voor foto’s lager op de pagina, maar de foto die meteen in beeld moet staan, wil je juist zo vroeg mogelijk laden.

• Een slider of video bovenaan die eerst veel scripts moet laden.

Interaction to next paint: reageert je site?

INP meet hoe snel je pagina reageert als iemand iets doet: op een knop tikken, een menu openen, een filter aanklikken of iets in een formulier typen. Het cijfer kijkt naar alle interacties tijdens een bezoek en rapporteert een van de traagste. Voelt je site ‘stroperig’ aan, dan zie je dat hier terug.

INP verving in 2024 de oudere meting First Input Delay (FID). Kom je FID nog tegen in een oud rapport of artikel, dan weet je dat het niet meer meetelt.

De oorzaak van een slechte INP is bijna altijd JavaScript. De browser is bezig met scripts en heeft geen tijd om op je bezoeker te reageren. Denk aan:

• Plugins die op elke pagina hun code laden, ook waar je ze niet gebruikt.

• Chatwidgets, cookiebanners en trackingcodes die allemaal tegelijk starten.

• Zware paginabouwers met veel animaties.

Hier helpt opruimen meer dan iets toevoegen. Elke plugin of tag die je weghaalt, geeft de browser lucht.

Cumulative layout shift: verspringt je pagina?

CLS meet hoeveel elementen onverwacht verschuiven terwijl de pagina laadt. Je wilt op ‘Offerte aanvragen’ tikken, er verschijnt net een banner boven en je tikt op iets anders. Dat is precies wat dit cijfer vastlegt. Het is geen tijd maar een score zonder eenheid: hoe lager, hoe beter.

Volgens web.dev zijn dit de bekendste oorzaken:

• Afbeeldingen en video’s zonder vaste breedte en hoogte, zodat de browser pas ruimte maakt als het bestand binnen is.

• Webfonts die groter of kleiner uitvallen dan het lettertype dat eerst even te zien is.

• Advertenties en widgets die na het laden van grootte veranderen.

• Balken of meldingen die bovenaan worden ingevoegd en de rest van de pagina omlaag duwen.

Waar zie je je Core Web Vitals?

Je hebt twee plekken nodig:

• PageSpeed Insights: per pagina, met bovenaan de cijfers van echte bezoekers over de afgelopen 28 dagen en daaronder een labtest met verbeterpunten. Hoe je dat rapport leest, staat in het artikel website snelheid testen.

• Google Search Console: het rapport Core Web Vitals laat zien welke groepen pagina’s op je site goed, matig of slecht scoren. Handig om te zien of het om één pagina gaat of om een sjabloon dat overal terugkomt. Heb je Search Console nog niet, lees dan hoe je Google Search Console instelt.

Heeft je site weinig bezoekers, dan heeft Google soms te weinig metingen. Je ziet dan geen praktijkcijfers, alleen de labtest. Gebruik die dan als richtlijn.

Hoe zwaar wegen Core Web Vitals voor Google?

Core Web Vitals horen bij de signalen die Google gebruikt om de pagina-ervaring te beoordelen. Ze wegen niet zwaarder dan een goed antwoord op de zoekvraag: een trage pagina met de beste inhoud kan nog steeds bovenaan staan. Maar staan twee pagina’s inhoudelijk dicht bij elkaar, dan helpt een goede ervaring. En los van Google: een bezoeker die moet wachten of mis tikt, vraagt minder snel een offerte aan.

Drie misverstanden

‘Mijn PageSpeed-score is 55, dus mijn Core Web Vitals zijn slecht’

Niet per se. De score van 0 tot 100 komt uit een gesimuleerde test op één nagebootste telefoon. De Core Web Vitals komen uit metingen bij echte bezoekers. Die twee kunnen flink verschillen. Google gebruikt de praktijkcijfers.

‘Op mijn computer is de site toch snel?’

Jij hebt waarschijnlijk een snelle computer, een goede verbinding en de site al in je cache. Je klant zit in de trein met een telefoon van een paar jaar oud. Kijk daarom altijd naar de mobiele cijfers.

‘Ik heb het opgelost, maar het rapport is nog rood’

De praktijkcijfers gaan over de afgelopen 28 dagen. Een verbetering van vandaag telt dus pas na een paar weken volledig mee. In Search Console kun je een probleem na het oplossen laten valideren; Google houdt de pagina’s dan een tijd in de gaten.

Waar begin je?

1. Kijk in Search Console welk cijfer rood of oranje staat en bij welke pagina’s.

2. Test een van die pagina’s in PageSpeed Insights op mobiel en noteer de cijfers.

3. Pak per cijfer de oorzaak aan: afbeeldingen en caching voor LCP, scripts en plugins voor INP, vaste afmetingen en rustige banners voor CLS.

4. Wacht een paar weken. De praktijkcijfers gaan over 28 dagen, dus een verbetering zie je niet de volgende ochtend.

Werk je met WordPress, dan staan de stappen op volgorde in het artikel WordPress sneller maken.

Liever laten regelen?

Wil je dat iemand je Core Web Vitals in de gaten houdt en de oorzaken oplost, kijk dan naar ons WordPress-onderhoud. Ligt het aan je server, dan is WordPress-hosting de volgende stap.