Core web vitals check

Ken je dat gevoel dat je website “best snel” lijkt, maar Google of je bezoekers toch afhaken? Dan is een Core web vitals check vaak de reality check die je nodig hebt. In dit artikel laat ik je in normale mensentaal zien wat Google precies meet, welke drempels er gelden voor LCP, INP en CLS, en hoe je de uitslagen goed interpreteert. Je krijgt ook een praktisch stappenplan met tools zoals PageSpeed Insights en Search Console, plus concrete optimalisaties die meestal het meeste opleveren. Doel: snel zien wat er misgaat en vooral wat je als eerste moet aanpakken.

Wat is een Core Web Vitals check en waarom zou je ‘m serieus nemen?

Core Web Vitals in één zin

Een Core Web Vitals check is het meten van drie Google metrics die de gebruikerservaring samenvatten: hoe snel de belangrijkste content verschijnt, hoe vlot je site reageert op acties, en of de layout rustig blijft staan. Sinds 2021 zijn dit signalen binnen Google’s page experience en ze wegen vooral mee als je concurrerende zoekresultaten hebt waar meerdere pagina’s inhoudelijk vergelijkbaar zijn.

Mijn eerlijke kijk op de SEO impact

Ik vind dat Core Web Vitals vaak te mystiek worden gemaakt. Ze zijn geen magische knop voor nummer 1 posities. Maar ze zijn wél een “hygiënefactor”: als je scores slecht zijn, wordt het onnodig lastig om te winnen van sites die dezelfde intentie beter bedienen én sneller aanvoelen. Zeker mobiel zie ik CWV als een stille conversiekiller. Een pagina die net te laat reageert, voelt onbetrouwbaar, ook als de content goed is.

Wil je breder begrijpen hoe dit past in SEO, dan is het handig om het grotere plaatje te kennen via de voordelen van SEO.

De 3 Core Web Vitals metrics en de drempels (2026-proof)

LCP: Largest Contentful Paint

LCP meet hoe lang het duurt voordat het grootste zichtbare content element in de viewport is geladen. Dat is vaak een hero afbeelding, video of een groot tekstblok. Het zegt dus: wanneer voelt de pagina “echt” begonnen?

1. Goed: ≤ 2,5 seconden
2. Verbetering nodig: 2,5 tot 4 seconden
3. Slecht: > 4 seconden

Wat ik hier belangrijk vind: je optimaliseert LCP niet door overal kleine milliseconds te winnen, maar door het main element sneller te krijgen: server respons, render blocking resources en zware media zijn meestal de boosdoeners.

INP: Interaction to Next Paint (vervangt FID)

INP is sinds 12 maart 2024 de officiële vervanger van FID. Waar FID alleen de eerste interactie keek, kijkt INP naar de algehele responsiviteit tijdens het bezoek. Het meet de tijd van een gebruikersactie (klik, tik, toetsaanslag) tot de volgende paint waarin de UI reageert.

1. Goed: ≤ 200 ms
2. Verbetering nodig: 200 tot 500 ms
3. Slecht: > 500 ms

Mijn ervaring met analyses is dat INP vaak verslechtert door te veel JavaScript, drukke third party scripts en lange taken op de main thread. Als je site “net niet” responsief voelt, zit je meestal hier.

CLS: Cumulative Layout Shift

CLS meet onverwachte verschuivingen van elementen tijdens het laden of tijdens interactie. Denk aan een knop die opschuift omdat een banner later inlaadt. CLS is geen tijd, maar een score: hoe hoger, hoe slechter.

1. Goed: ≤ 0,1
2. Verbetering nodig: 0,1 tot 0,25
3. Slecht: > 0,25

CLS is in de praktijk vaak de makkelijkste quick win: ruimte reserveren voor afbeeldingen, advertenties en embeds levert snel resultaat op.

Field data vs lab data: waarom je twee soorten cijfers ziet

Field data (CrUX): de data waar Google op leunt

Field data komt uit het Chrome User Experience Report (CrUX) en is gebaseerd op echte bezoekers over ongeveer de laatste 28 dagen. Dit is de data die het dichtst bij Google’s beoordeling zit. Het nadeel: als je weinig verkeer hebt, kan er te weinig data zijn of wordt er gegroepeerd op origin niveau, waardoor je minder detail krijgt.

Lab data: perfect om te debuggen

Lab data is een gesimuleerde test in een gecontroleerde omgeving. Die is ideaal om oorzaken te vinden, bijvoorbeeld welke resource LCP vertraagt of welke script lange taken veroorzaakt. Het nadeel: het kan afwijken van de echte wereld. Een labtest op een snelle verbinding kan je CLS probleem wel laten zien, maar je LCP in het veld blijft misschien traag door serverbelasting of geografische latency.

Mijn advies: vertrouw op field data voor “is het goed genoeg?”, en gebruik lab data voor “wat moet ik fixen?”.

De beste tools voor een Core web vitals check (gratis en praktisch)

Google PageSpeed Insights: snel en bruikbaar

PageSpeed Insights is meestal de eerste tool die ik pak voor een single URL. Je krijgt zowel field data als lab data, plus concrete kansen en diagnostics. Let hierbij op de splitsing tussen mobiel en desktop en kijk niet alleen naar een totaalscore. Die score is handig, maar je wint de meeste tijd door de echte bottleneck per metric te fixen.

• Kies één belangrijke pagina, bijvoorbeeld je best bezochte landingspagina.
• Check mobiel eerst, omdat daar de meeste sites pijn hebben.
• Noteer LCP element, INP hints en CLS bronnen.
• Herhaal na changes en vergelijk.

Search Console Core Web Vitals report: het overzicht voor je hele site

Search Console is mijn favoriete tool om patronen te vinden. De CWV rapportage groepeert URL’s op “soortgelijke pagina’s” en geeft status Goed, Verbetering nodig of Slecht per device type. Belangrijk detail: de status van een groep is zo slecht als de slechtste metric. Dus één slechte CLS kan een hele groep “Slecht” maken, ook al is LCP prima.

Wat ik sterk vind aan Search Console: je ziet of het een issue is dat veel pagina’s raakt. Dat is vaak efficiënter dan één pagina tweaken. Wat minder is: het is niet gemaakt om snel een specifieke URL op te zoeken. Dan ga ik terug naar PageSpeed of Lighthouse.

Lighthouse en Chrome DevTools: als je wilt begrijpen “waarom”

Lighthouse in Chrome DevTools is ideaal voor debugging: waterfall, main thread werk, render blocking en screenshots tijdens het laden. Als je INP issues hebt, kom je vaak uit bij long tasks en event handlers. Hier zie je tenminste waar de tijd naartoe gaat.

Derde partijen: Uptrends, DebugBear en bulk checks

Tools zoals Uptrends zijn handig als je wilt testen vanaf meerdere locaties of devices en je rapportage deelbaar wilt maken. DebugBear en vergelijkbare tools zijn sterk in het uitleggen van INP problemen en in monitoring. Bulk checks zijn vooral nuttig als je veel URL’s hebt en niet wilt gokken welke pagina’s het meeste verkeer hebben.

• Uptrends: prettig voor wereldwijde locaties en visuele watervalrapporten.
• DebugBear: sterk in debug informatie en doorlopende monitoring.
• Bulk check tools: handig voor 100 plus URL’s om clusters te vinden.

Stappenplan: zo doe je een Core web vitals check zonder te verdwalen

Stap 1: kies je pagina’s slim

Begin niet met “de hele site”. Kies 5 tot 10 pagina’s die impact hebben: homepage, belangrijkste categorie, top 3 landingspagina’s, en een representatieve product of artikelpagina. Als je Search Console hebt, start daar: de tabellen met “Poor” en “Need improvement” zijn vaak direct raak.

Stap 2: check field data en bepaal prioriteit

Kijk per device type wat de status is. Mijn prioritering is meestal: eerst mobiel, daarna desktop. En binnen mobiel: fix eerst CLS als het slecht is, daarna LCP, daarna INP. CLS fixes zijn vaak goedkoop en leveren direct een beter gevoel op. LCP is vaak server en front end werk. INP kan diep in JavaScript en third party tooling zitten.

Stap 3: voer een labtest uit om de oorzaak te vinden

Open PageSpeed Insights of Lighthouse en let op:

1. Wat is het LCP element en wanneer laadt het?
2. Welke resources blokkeren render?
3. Zijn er long tasks die INP beïnvloeden?
4. Welke elementen veroorzaken layout shifts?

Tip: maak screenshots van before en after zodat je team dezelfde taal spreekt. Dat voorkomt eindeloze discussies over “het voelt sneller”.

Stap 4: optimaliseer in de juiste volgorde

Ik zou niet alles tegelijk aanpassen. Doe één set veranderingen, meet opnieuw, en herhaal. Je voorkomt zo dat je niet meer weet wat het effect heeft veroorzaakt.

Concrete verbeteringen per metric (de dingen die meestal echt werken)

LCP verbeteren: focus op server, hero content en render blocking

Als LCP te hoog is, zit het vaak in deze hoek. Dit zijn de verbeteringen die ik het vaakst terugzie in audits en die meestal het meest opleveren:

• Snellere TTFB: caching, efficiëntere backend, betere hosting en CDN.
• Optimaliseer afbeeldingen: juiste formaat, moderne compressie, responsive images.
• Prioriteer hero element: preload waar logisch, en voorkom dat het pas na veel scripts verschijnt.
• Beperk render blocking: kritieke CSS, uitstellen van niet kritieke scripts.

Wat me vaak zorgen baart: sites die hun LCP afhankelijk maken van een zware slider of video bovenaan. Het ziet er mooi uit, maar het is bijna altijd een performance schuld die je later terugbetaalt.

INP verbeteren: minder main thread drukte en slimmer met scripts

INP is de metric waar marketing tooling en tracking snel roet in het eten gooien. Denk aan chatwidgets, heatmaps, tag managers en A B testing. Mijn aanpak:

• Verwijder of vervang scripts die weinig waarde leveren.
• Stel third party scripts uit tot na interactie of na belangrijke renders.
• Splits JavaScript en laad alleen wat nodig is voor de pagina.
• Voorkom long tasks door werk op te knippen.

Als je afhankelijk bent van veel scripts, overweeg dan een structurele inventarisatie. Het is vaak pijnlijk hoeveel “kleine” tools samen je interactiviteit slopen.

CLS verbeteren: reserveer ruimte en wees streng op banners

CLS issues komen vaak door dingen die later in de flow worden geduwd. Dit is mijn checklist:

• Geef afbeeldingen en video’s vaste afmetingen via width en height of aspect ratio.
• Reserveer ruimte voor ads en embeds, ook als ze soms niet laden.
• Wees voorzichtig met cookie banners en sticky bars die content wegduwen.
• Let op fonts: voorkom grote verspringingen bij font swap.

Een kleine maar belangrijke nuance: overlays die bovenop content verschijnen zonder de layout te verschuiven, zijn meestal beter voor CLS dan elementen die de hele pagina omlaag duwen.

Mobiel, locaties en fluctuaties: zo voorkom je verkeerde conclusies

Mobiel eerst is geen slogan, maar realiteit

Google beoordeelt mobiel zwaar en je echte gebruikers zitten op allerlei netwerken. Test dus altijd mobiel en liefst met verschillende verbindingen. Een labtest op een snelle desktop kan je het gevoel geven dat alles goed is, terwijl je field data op mobiel “Needs improvement” blijft.

Waarom je scores kunnen veranderen zonder dat jij iets deed

Field data is een aggregatie over 28 dagen. Je status kan dus schuiven door:

• Meer verkeer tijdens een campagne waardoor servers drukker worden
• Een wijziging bij je CDN, image host of third party scripts
• Meer bezoekers uit regio’s met langzamere netwerken
• Borderline metrics die net over een drempel vallen

Dit is precies waarom ik monitoring waardevol vind: je wilt regressies zien voordat ze wekenlang in CrUX blijven hangen.

Core Web Vitals in je SEO aanpak: meten, verbeteren, bewaken

Koppel CWV aan business pagina’s

De beste CWV verbeteringen zijn degene die effect hebben op pagina’s die geld of leads opleveren. Ik zou dus altijd beginnen met pagina’s die ranken op waardevolle zoekwoorden of die veel conversies pakken. Als je dat proces wilt structureren, kan een SEO benchmark helpen om prestaties en prioriteiten scherp te krijgen.

Technische fixes die je SEO ook kunnen breken

Let op dat performance optimalisaties soms SEO schade kunnen veroorzaken, bijvoorbeeld door verkeerd ingestelde redirects of caches. Als je URL’s gaat aanpassen, zorg dat je redirects netjes staan. Dit artikel over 301 redirects instellen is daarbij een goede basis.

Maak het onderdeel van je release proces

Wat ik “volwassen” websites zie doen: elke release heeft een performance check. Niet omdat het leuk is, maar omdat nieuwe scripts, nieuwe banners en nieuwe templates anders langzaam je INP en CLS opblazen. Een simpele regel helpt al: bij elke grote wijziging één PageSpeed check op mobiel voor de belangrijkste templates.

Veelgestelde vragen

Wat is het verschil tussen PageSpeed Insights en Search Console bij een Core web vitals check?

PageSpeed Insights is vooral bedoeld voor een snelle check van één URL met lab en field data plus concrete verbeterpunten. Search Console geeft een sitebreed overzicht op basis van CrUX field data en groepeert vergelijkbare pagina’s. Ik gebruik Search Console om patronen te vinden en PageSpeed om te debuggen en fixes te valideren.

Waarom zie ik “No data available” in mijn Core web vitals check?

Meestal is er te weinig CrUX field data, bijvoorbeeld bij nieuwe sites of pagina’s met weinig verkeer. Search Console toont dan geen betrouwbare groepstatus. Gebruik in dat geval labtests via PageSpeed Insights of Lighthouse, en bouw ondertussen traffic op. Na een paar weken kan er alsnog genoeg field data beschikbaar komen.

Hoe lang duurt het voordat verbeteringen zichtbaar zijn in Core Web Vitals?

Field data wordt doorgaans over de laatste 28 dagen geaggregeerd. Daardoor kan het weken duren voordat je volledige effect zichtbaar is in CrUX en Search Console. Labdata in PageSpeed Insights kan meteen verbeteren, maar dat is niet hetzelfde als de “echte wereld” beoordeling. Meet dus direct in lab en blijf 4 weken volgen.

Welke metric moet ik als eerste fixen bij een slechte Core web vitals check?

Als CLS slecht is, pak ik die meestal eerst aan omdat het vaak snelle, duidelijke wins zijn. Daarna richt ik me op LCP, omdat dat sterk samenhangt met laadtijdgevoel en server performance. INP doe ik daarna, tenzij je site echt traag reageert; dan kan INP prioriteit krijgen door zware scripts.

Kan ik Core Web Vitals ook monitoren zonder dure tooling?

Ja. Met Search Console heb je al een gratis field data overzicht en met PageSpeed Insights kun je ad hoc tests draaien. Voor meer continu inzicht kun je de Web Vitals extensie in Chrome gebruiken of zelf meten met de web vitals JavaScript library. Betaalde tools zijn vooral handig voor alerts en bulk rapportage.

Een goede Core web vitals check draait niet om één score, maar om het begrijpen van LCP, INP en CLS en het slim combineren van field data en lab data. Mijn advies: start met Search Console om de grootste groepen problemen te vinden, gebruik PageSpeed of Lighthouse om de oorzaak te pinpointen, en optimaliseer in duidelijke rondes. Als je dat ritme vasthoudt, worden je pagina’s niet alleen “Google vriendelijker”, maar vooral merkbaar prettiger voor echte bezoekers.