Last Updated on 8 augustus 2026 by connectyourworld

Een website kan inhoudelijk uitstekend zijn en toch frustrerend werken. Een pagina die langzaam verschijnt, een knop die niet direct reageert of tekst die tijdens het lezen plotseling verspringt, zorgt voor een slechte gebruikerservaring. Google probeert deze onderdelen meetbaar te maken met de Google Core Web Vitals.
Core Web Vitals meten drie belangrijke onderdelen van de gebruikerservaring: laadsnelheid, responsiviteit en visuele stabiliteit. Daarvoor gebruikt Google de metrics Largest Contentful Paint (LCP), Interaction to Next Paint (INP) en Cumulative Layout Shift (CLS).
Voor SEO is het belangrijk om deze waarden serieus te nemen. Goede Core Web Vitals zijn geen garantie dat u bovenaan in Google komt, maar een goede page experience sluit wel aan bij wat Google met zijn rankingsystemen probeert te belonen.
In deze gids leggen we niet alleen uit wat Core Web Vitals zijn. U leert vooral hoe u problemen opspoort en welke verbeteringen u vervolgens kunt uitvoeren.
Google Core Web Vitals zijn prestatiestatistieken waarmee Google kijkt naar de werkelijke ervaring van bezoekers op een webpagina.
Daarbij staan drie vragen centraal:
Hoe snel verschijnt de belangrijkste content?
Dit wordt gemeten met Largest Contentful Paint (LCP).
Hoe snel reageert de website wanneer iemand iets doet?
Dit wordt gemeten met Interaction to Next Paint (INP).
Blijft de pagina tijdens het laden visueel stabiel?
Dit wordt gemeten met Cumulative Layout Shift (CLS).
Een website kan dus snel aanvoelen, maar toch slecht scoren op INP omdat knoppen of menu’s traag reageren. Andersom kan een pagina snel laden, maar een slechte CLS hebben doordat afbeeldingen, advertenties of andere elementen tijdens het laden verspringen.
Google hanteert duidelijke grenswaarden.
| Core Web Vital | Wat wordt gemeten? | Goed | Verbetering nodig | Slecht |
|---|---|---|---|---|
| LCP | Laadervaring | ≤ 2,5 sec | 2,5–4 sec | > 4 sec |
| INP | Responsiviteit | ≤ 200 ms | 200–500 ms | > 500 ms |
| CLS | Visuele stabiliteit | ≤ 0,1 | 0,1–0,25 | > 0,25 |
Het gaat daarbij niet alleen om één bezoeker of één meting. Voor de beoordeling van Core Web Vitals wordt gekeken naar het 75e percentiel. Praktisch betekent dit dat een goede ervaring voor minimaal ongeveer 75% van de bezoeken het uitgangspunt is.
Largest Contentful Paint meet hoe lang het duurt voordat het grootste relevante zichtbare contentelement in beeld wordt weergegeven.
Denk bijvoorbeeld aan:
Een LCP van maximaal 2,5 seconden wordt als goed beschouwd.
Stel dat een loodgietersbedrijf een lokale landingspagina heeft. Bovenaan staat een grote foto van een monteur van 2 MB.
De bezoeker opent de pagina op een mobiele telefoon. De navigatie en tekst verschijnen, maar de grote afbeelding blijft nog enkele seconden laden.
Als die afbeelding het grootste zichtbare element is, kan deze verantwoordelijk zijn voor een slechte LCP.
Alleen zeggen dat “de website langzaam is” helpt dan niet. U moet achterhalen welk element verantwoordelijk is voor de LCP en waarom dat element te laat verschijnt.
Begin bij het LCP-element zelf.
Comprimeer grote afbeeldingen en gebruik moderne, efficiënte afbeeldingsformaten waar dat passend is. Zorg dat de belangrijkste afbeelding niet onnodig wordt vertraagd en controleer of CSS, JavaScript of externe scripts het weergeven van de belangrijkste content blokkeren.
Ook een trage serverrespons kan een belangrijke oorzaak zijn. Wanneer de server al veel tijd nodig heeft voordat de eerste informatie wordt verstuurd, wordt het moeilijker om binnen 2,5 seconden een goede LCP te behalen.
Praktische tip: probeer niet willekeurig tien optimalisaties tegelijk uit te voeren. Zoek eerst in PageSpeed Insights of Lighthouse uit welk element als LCP wordt aangemerkt. Pak daarna de oorzaak aan.
Interaction to Next Paint meet de responsiviteit van een pagina tijdens het bezoek.
INP kijkt naar interacties zoals klikken, tikken en het gebruik van het toetsenbord en meet hoe snel de pagina daarop visueel reageert.
Een goede INP is maximaal 200 milliseconden.
INP heeft in maart 2024 de voormalige Core Web Vital First Input Delay (FID) vervangen. INP geeft een breder beeld van de responsiviteit gedurende het bezoek dan FID deed.
Een bezoeker bekijkt op een webshop een product en klikt op ‘In winkelwagen’.
Er gebeurt ogenschijnlijk niets.
Na een halve seconde verandert de knop en wordt het product toegevoegd.
Een halve seconde lijkt weinig, maar de gebruiker merkt die vertraging wel degelijk. Mogelijk klikt iemand zelfs nogmaals omdat het lijkt alsof de eerste klik niet is geregistreerd.
Een mogelijke oorzaak is dat de browser op dat moment druk bezig is met het uitvoeren van zware JavaScript-taken.
Onderzoek eerst welke interacties langzaam reageren. Kijk vervolgens kritisch naar JavaScript.
Verwijder scripts die niet noodzakelijk zijn, beperk zware taken op de main thread en kijk kritisch naar externe scripts van bijvoorbeeld chatfuncties, trackingsoftware, advertenties en andere plug-ins.
Voor WordPress-websites is het bovendien verstandig om kritisch te kijken naar het aantal plug-ins. Het aantal alleen zegt niet alles: vooral wat een plug-in op de frontend uitvoert is belangrijk.
Praktische tip: een website kan snel openen en toch een slechte INP hebben. Test daarom niet alleen hoe snel de homepage verschijnt, maar gebruik daadwerkelijk menu’s, filters, formulieren en knoppen.
Cumulative Layout Shift meet onverwachte verschuivingen van zichtbare onderdelen van een pagina.
Een goede CLS-score is maximaal 0,1.
Iedereen kent waarschijnlijk een voorbeeld.
U wilt op een knop klikken. Op het laatste moment verschijnt boven de knop een afbeelding of advertentie. De inhoud schuift naar beneden en u klikt per ongeluk ergens anders op.
Dat is precies het soort gebruikerservaring dat CLS probeert te meten.
Een bezoeker leest een blog.
Boven een alinea moet nog een afbeelding worden geladen. Voor deze afbeelding is vooraf geen ruimte gereserveerd.
Wanneer de afbeelding uiteindelijk verschijnt, schuift de tekst die de bezoeker aan het lezen was plotseling naar beneden.
Dit kan een layout shift veroorzaken.
Reserveer vooraf voldoende ruimte voor afbeeldingen, video’s, advertenties en embeds. Geef afbeeldingen bijvoorbeeld de juiste afmetingen mee, zodat de browser al weet hoeveel ruimte nodig is voordat het bestand volledig geladen is.
Let daarnaast op webfonts en content die achteraf boven bestaande content wordt toegevoegd.
Praktische tip: controleer vooral onderdelen die pas ná het openen van de pagina verschijnen, zoals cookiebanners, advertenties, formulieren, pop-ups en dynamische widgets.
Een veelgemaakte fout is uitsluitend kijken naar de grote Performance Score van PageSpeed Insights.
Een score van bijvoorbeeld 92/100 is niet hetzelfde als “geslaagd voor Core Web Vitals”.
PageSpeed Insights kan namelijk verschillende soorten informatie laten zien.
Field data bestaat uit praktijkgegevens van echte Chrome-gebruikers en komt uit het Chrome User Experience Report (CrUX).
Deze gegevens zijn bijzonder waardevol omdat ze rekening houden met echte omstandigheden.
Uw bezoekers hebben immers niet allemaal dezelfde:
De werkelijkheid is daardoor veel gevarieerder dan één technische test.
Lab data wordt onder gecontroleerde omstandigheden gemeten. PageSpeed Insights gebruikt hiervoor Lighthouse.
Dit is vooral handig voor het diagnosticeren van technische problemen.
Een eenvoudige manier om het verschil te onthouden is:
Field data vertelt u dát bezoekers een probleem ervaren.
Lab data helpt u onderzoeken waar het probleem vandaan kan komen.
Dit zorgt regelmatig voor verwarring.
U voert een test uit in PageSpeed Insights en krijgt een goede score. Vervolgens opent u Google Search Console en ziet u URL’s met Core Web Vitals-problemen.
Dat hoeft geen tegenstrijdigheid te zijn.
Een Lighthouse-test is een gesimuleerde momentopname onder bepaalde omstandigheden. De Core Web Vitals-veldgegevens zijn gebaseerd op ervaringen van echte gebruikers over een langere periode.
Daarom kan een technische aanpassing vandaag een duidelijk betere Lighthouse-score opleveren, terwijl de veldgegevens niet onmiddellijk hetzelfde beeld laten zien.

Wilt u structureel te werk gaan? Gebruik dan deze aanpak.
Stap 1 – Open PageSpeed Insights
Voer de URL van de pagina in die u wilt onderzoeken. Test niet alleen de homepage. Belangrijke landingspagina’s, categoriepagina’s, productpagina’s en blogs kunnen onderling sterk verschillen.
Stap 2 – Bekijk eerst de Core Web Vitals
Controleer LCP, INP en CLS en kijk welke metric aandacht nodig heeft.
Stap 3 – Kijk naar mobiele prestaties
Mobiele bezoekers hebben regelmatig te maken met minder krachtige apparaten en wisselende netwerkverbindingen. Problemen kunnen daardoor op mobiel duidelijker zichtbaar worden.
Stap 4 – Onderzoek de diagnostische gegevens
Is LCP slecht? Zoek het LCP-element en onderzoek de laadtijd.
Is INP slecht? Onderzoek JavaScript, de main thread en zware interacties.
Is CLS slecht? Zoek naar elementen die tijdens of na het laden verschuiven.
Stap 5 – Controleer Google Search Console
Bekijk het rapport Core Web Vitals om probleemgroepen en ontwikkelingen te volgen.
Stap 6 – Verbeter één probleem gericht
Voer niet blind alle aanbevelingen uit. Begin met de problemen die daadwerkelijk invloed hebben op de slechte Core Web Vital.
Stap 7 – Test opnieuw
Gebruik Lighthouse of PageSpeed Insights om te controleren of de technische wijziging effect heeft.
Stap 8 – Volg de veldgegevens
Een goede technische test is mooi, maar uiteindelijk wilt u dat echte bezoekers een betere ervaring krijgen.
Stel:
Een dienstenpagina heeft een LCP van 4,3 seconden.
PageSpeed Insights laat zien dat de grote afbeelding bovenaan de pagina het LCP-element is.
Dan heeft het weinig zin om als eerste tientallen kleine CSS-bestanden te optimaliseren als daar nauwelijks winst te behalen valt.
Een logisch stappenplan is:
1. Controleer de bestandsgrootte van de afbeelding.
2. Controleer of een efficiënter formaat mogelijk is.
3. Controleer of de afbeelding in de juiste afmetingen wordt geladen.
4. Controleer of de afbeelding onnodig laat wordt ontdekt of geladen.
5. Onderzoek de serverrespons wanneer de LCP ondanks beeldoptimalisatie slecht blijft.
6. Test opnieuw.
Zo verandert Core Web Vitals-optimalisatie van “website sneller maken” in een concreet technisch proces.
Bij WordPress wordt al snel geroepen: “Installeer een cachingplug-in.”
Caching kan zeker helpen, maar lost niet automatisch ieder Core Web Vitals-probleem op.
Heeft een website bijvoorbeeld een slechte INP door veel JavaScript van externe tools, dan kan alleen caching onvoldoende effect hebben.
Een betere volgorde is:
meten → probleem vaststellen → oorzaak onderzoeken → oplossing uitvoeren → opnieuw meten.
Pas daarna bepaalt u welke plug-in, technische aanpassing of hostingverbetering nodig is.
Met een slechte LCP zien we bijvoorbeeld zware hero-afbeeldingen, een trage serverrespons of belangrijke resources die te laat worden geladen.
Bij INP kunnen grote hoeveelheden JavaScript, zware frontendfunctionaliteiten en externe scripts een rol spelen.
Bij CLS zijn afbeeldingen zonder gereserveerde ruimte, advertenties, embeds, fonts en dynamisch ingevoegde content bekende aandachtspunten.
Het belangrijkste is dat u niet vanuit de oplossing redeneert.
“Ik heb een slechte Core Web Vitals-score, dus ik heb een cachingplug-in nodig” is geen goede diagnose.
Begin bij de metric en zoek vervolgens de oorzaak.
Core Web Vitals spelen een rol binnen Google’s rankingsystemen, maar de relatie met rankings moet niet worden overdreven.
Een website met perfecte Core Web Vitals gaat niet automatisch boven een concurrent staan met relevantere en betere content.
Google kijkt veel breder naar page experience en relevantie.
Zie Core Web Vitals daarom niet als een truc om hoger in Google te komen.
Zie ze als onderdeel van een goede website.
Wanneer twee websites beide uitstekende informatie bieden, wilt u niet degene zijn waarvan de pagina langzaam reageert, verspringt of slecht werkt op mobiele apparaten.
Nee.
Een obsessie met een perfecte Lighthouse-score kan zelfs betekenen dat tijd en budget worden besteed aan optimalisaties waarvan bezoekers nauwelijks iets merken.
Het doel is niet:
100/100 halen omdat het mooi staat.
Het doel is:
een snelle, stabiele en responsieve website voor echte bezoekers realiseren.
Gebruik scores daarom als hulpmiddel en niet als einddoel.
Controleer bij een technische optimalisatie in ieder geval:
LCP
INP
CLS
De grootste fout bij snelheidsoptimalisatie is direct beginnen met technische aanpassingen.
Een cachingplug-in installeren, afbeeldingen comprimeren en JavaScript verkleinen klinkt nuttig, maar zonder diagnose weet u niet of u het werkelijke probleem oplost.
Werk daarom altijd in deze volgorde:
Meten → analyseren → prioriteren → verbeteren → testen → monitoren.
Daarmee voorkomt u dat tientallen kleine optimalisaties worden uitgevoerd terwijl één groot probleem verantwoordelijk is voor de slechte gebruikerservaring.
Heeft uw website slechte Core Web Vitals of weet u niet waarom bepaalde pagina’s langzaam laden of reageren? Dan is het verstandig om eerst vast te stellen welke metric onvoldoende scoort en waardoor dit wordt veroorzaakt.
Connect your World kijkt daarbij verder dan alleen een algemene PageSpeed-score. We bekijken technische SEO, snelheid, mobiele gebruikservaring en de invloed daarvan op de totale SEO-prestaties van de website.
Zo wordt niet zomaar “de website sneller gemaakt”, maar wordt gericht gewerkt aan technische verbeteringen die daadwerkelijk relevant zijn voor bezoekers en zoekmachines.
De huidige Core Web Vitals zijn Largest Contentful Paint (LCP), Interaction to Next Paint (INP) en Cumulative Layout Shift (CLS). Ze meten respectievelijk laadprestaties, responsiviteit en visuele stabiliteit.
Google adviseert een Largest Contentful Paint van maximaal 2,5 seconden.
Een INP van maximaal 200 milliseconden wordt als goed beschouwd. Boven 500 milliseconden valt de score in de categorie slecht.
Een CLS van maximaal 0,1 geldt als goed. Een hogere waarde betekent dat bezoekers relatief veel onverwachte verschuivingen van de pagina kunnen ervaren.
Interaction to Next Paint heeft First Input Delay in maart 2024 vervangen als Core Web Vital. INP kijkt breder naar de responsiviteit van een pagina gedurende het bezoek.
Core Web Vitals worden gebruikt door Google’s rankingsystemen, maar goede scores garanderen geen hoge positie. Relevantie en andere aspecten van de kwaliteit van een pagina blijven eveneens belangrijk.
Een Lighthouse-test vindt plaats onder gesimuleerde omstandigheden. Netwerkcondities en andere omstandigheden kunnen invloed hebben op afzonderlijke tests. Daarnaast moet onderscheid worden gemaakt tussen lab data en gegevens van echte gebruikers.
U kunt verschillende soorten gegevens met elkaar vergelijken. Een Lighthouse-test is een gesimuleerde test, terwijl Core Web Vitals-veldgegevens gebaseerd zijn op ervaringen van echte gebruikers over een langere periode.
Controleer ze in ieder geval na belangrijke technische wijzigingen, een nieuw WordPress-thema, aanpassingen aan templates of de toevoeging van zware scripts en functionaliteiten. Voor belangrijke SEO-pagina’s is periodieke monitoring verstandig.
Nee. Caching kan bepaalde laadproblemen verbeteren, maar een slechte INP of CLS kan een heel andere oorzaak hebben. Stel daarom eerst vast welke metric onvoldoende scoort.
Nee. Een perfecte Lighthouse-score is geen vereiste voor goede Core Web Vitals of goede Google-posities. Richt u vooral op een aantoonbaar goede ervaring voor echte bezoekers
Google Core Web Vitals zijn vooral waardevol omdat ze technische prestaties vertalen naar iets dat iedere website-eigenaar zou moeten begrijpen: wat ervaart mijn bezoeker?
Kan iemand de belangrijkste content snel zien? Reageert de website direct wanneer iemand klikt? Blijft de pagina tijdens het laden stabiel?
Daarom begint goede Core Web Vitals-optimalisatie niet bij een score van 100, een nieuwe plug-in of het blind opvolgen van iedere PageSpeed-waarschuwing.
Het begint bij drie cijfers: LCP, INP en CLS.
Bepaal welke onvoldoende scoort, zoek de oorzaak en los vervolgens gericht het probleem op. Daarmee werkt u niet alleen aan technische SEO, maar vooral aan een website die prettiger en sneller werkt voor de mensen die hem daadwerkelijk gebruiken.

