Core Web Vitals: Google beoordeelt je snelheid per pagina, maar je rapport groepeert ze
Google beoordeelt de snelheid van je website per pagina, op het 75e percentiel van wat echte bezoekers in 28 dagen meemaakten. Search Console laat dat alleen niet per losse URL zien: het rapport bundelt pagina's met een vergelijkbare ervaring in een groep, en bij te weinig gegevens valt het terug op een groep voor je hele domein. Daardoor kleurt een trage sjabloonpagina een hele groep rood. Begin daarom bij je traagste pagina's, niet bij je homepage.
Wat zijn Core Web Vitals en waarom doen ze ertoe
Core Web Vitals zijn drie meetwaarden waarmee Google bepaalt hoe snel en prettig je website is voor bezoekers. Het zijn geen suggesties maar harde cijfers die direct je posities in de zoekresultaten beïnvloeden.
LCP (Largest Contentful Paint)
meet hoe snel het grootste zichtbare element laadt. De drempel van Google: 2,5 seconden.INP (Interaction to Next Paint)
vervangt sinds maart 2024 de oude FID-meting en meet hoe snel je site reageert op interactie van de gebruiker. Drempel: 200 milliseconden.CLS (Cumulative Layout Shift)
meet onverwachte verschuivingen van elementen tijdens het laden. Gewenste waarde: onder de 0,1.Google beoordeelt deze waarden per pagina, op het 75e percentiel van de echte gebruikersdata; zo staat het in de uitleg van Google over Core Web Vitals. Wil je eerst de basis opfrissen, kijk dan in onze kennisbank.
Waarom je rapport pagina's op een hoop gooit
Je leest wel eens dat Google sinds maart 2026 je hele site als geheel beoordeelt, onder de naam composite CWV scoring. Die wijziging heeft nooit plaatsgevonden en die term komt niet van Google. Wat er wel is: Google beoordeelt page experience per pagina en heeft nooit een samengestelde sitescore aangekondigd.
De verwarring komt uit je rapport
Search Console bundelt URL's met een vergelijkbare gebruikerservaring tot een groep en geeft de hele groep dezelfde status. Heeft een groep te weinig gegevens, dan valt het rapport terug op een groep voor je hele domein. Daardoor kleurt een trage sjabloonpagina een hele groep rood, ook als de rest van die groep snel is. Dat is een weergave in je rapport en geen sitebrede rankingbeoordeling.
Waarom een trage pagina zijn hele groep meetrekt
Een groep in Search Console krijgt de status van de slechtst presterende URL's erin. Tien snelle pagina's in dezelfde groep maken dat niet goed: je ziet rood, en je ziet niet meteen welke URL het veroorzaakt.
Geen kleinigheid, want dat rapport is waar je maand in maand uit op stuurt
Zolang je groep rood staat weet je niet of je probleem bij een enkel sjabloon zit of overal, en je gaat vaak de verkeerde pagina versnellen.
Tip: open de rode groep, sorteer op de slechtste URL's en begin daar
Een trage pagina repareren levert meer op dan tien snelle pagina's nog verder versnellen.
Zo kom je erachter of jouw site een probleem heeft
Je hoeft niet te gokken. Met drie gratis hulpmiddelen zie je binnen een paar minuten waar je staat.
Google Search Console
open het rapport Core Web Vitals in het linkermenu en kijk hoeveel pagina's als slecht worden beoordeeld. Meer dan 20 procent duidt op een probleem.PageSpeed Insights
ga naar pagespeed.web.dev en voer je URL in. Test niet alleen je homepage, maar ook je contactpagina, blogposts en dienstpagina's.Site Kit voor WordPress
deze plugin koppelt je Search Console-data direct aan je WordPress-dashboard.Alleen je homepage controleren is een veelgemaakte fout. Juist de vergeten pagina's dieper in je site trekken de score omlaag.
Wat je nu moet doen: vijf concrete stappen
Stap 1: inventariseer je slechtste pagina's
Open Search Console, ga naar het Core Web Vitals-rapport en sorteer op slecht. Dit zijn je prioriteiten.Stap 2: pak je afbeeldingen aan
Op mkb-sites is dit de oorzaak die wij het vaakst tegenkomen. Een percentage laten we er bewust weg, want dat is een indruk uit ons eigen werk en geen meting. Comprimeer ze tot onder de 200 KB, gebruik het WebP-formaat en zet lazy loading aan. Plugins als ShortPixel of Imagify automatiseren dit.Stap 3: ruim je scripts op
Elke plugin, widget, tracker en chatbot vertraagt je pagina. Verwijder wat je niet echt nodig hebt.Stap 4: fix je hosting
Goedkope shared hosting is vaak onvoldoende. Managed WordPress-hosting met caching en CDN heeft meetbare impact, maar de instaptarieven lopen uiteen: Cloudways begint rond 11 dollar per maand, Kinsta rond 35 dollar en WP Engine daartussenin. Reken voor een zakelijke site met echt verkeer op 30 tot 50 euro per maand, en kijk naar wat er in dat bedrag zit aan CDN, back-ups en een testomgeving.Stap 5: verwijder of verbeter oude pagina's
Pagina's met een slechte score en geen verkeer kun je beter verwijderen en redirecten naar een relevante pagina.Tip: denk aan de 80/20-regel als vuistregel en niet als meting: in de praktijk zit het grootste deel van je snelheidsprobleem in een klein deel van je pagina's.
Kom je er zelf niet uit, dan pakken wij dit voor je op als onderdeel van SEO verbeteren.
De meest voorkomende snelheidsvreters op mkb-websites
Ongecomprimeerde afbeeldingen
de grootste boosdoener. Een foto van zes megabyte op pagina 17 kan de score van je hele site kapotmaken.Te veel plugins
op de meeste sites die wij openen staan plugins die ooit ergens voor zijn aangezet en daarna nooit zijn opgeruimd. Tel ze en vraag per plugin waarvoor hij er vandaag nog staat.Geen caching
het verschil kan oplopen tot 3 tot 4 seconden laadtijd per pagina.Externe scripts van derden
Google Analytics, Facebook Pixel, HotJar, Google Tag Manager. Elk extra verzoek vertraagt je pagina.Embedded content
een YouTube-embed laadt een complete speler met eigen scripts mee, en dat kost merkbaar tijd. Hoeveel precies verschilt per pagina, dus meet het zelf een keer met en zonder. Gebruik een thumbnail met play-knop die de video pas laadt bij een klik.Wil je breder kijken dan snelheid alleen? Lees dan hoe je gevonden wordt in Google AI Overviews en ChatGPT.
Veldgegevens en labgegevens: waarom PageSpeed twee uitslagen geeft
Voer je een pagina in bij PageSpeed Insights, dan krijg je twee blokken onder elkaar, en die spreken elkaar geregeld tegen. Bovenaan staan de veldgegevens: wat echte bezoekers met echte toestellen op echte verbindingen in de afgelopen 28 dagen hebben meegemaakt. Daaronder staat de labmeting van Lighthouse: een simulatie, op dit moment, op een nagebootst toestel en een nagebootste verbinding.
Alleen dat eerste blok telt mee voor de beoordeling
De veldgegevens komen uit het Chrome User Experience Report, de verzameling die Chrome opbouwt uit bezoekers die daarvoor toestemming hebben gegeven; zie de documentatie van het Chrome User Experience Report, gecontroleerd op 25 augustus 2026. De labmeting is diagnostiek, geen oordeel.
Ze lopen uit elkaar omdat het lab dingen niet kent
Geen cache, geen ingelogde sessie, geen bezoeker die halverwege scrollt of op een knop tikt. INP ontbreekt in het lab zelfs helemaal, want zonder interactie valt er niets te meten. Andersom mist het veld de dwarsdoorsnede: het vertelt je dat het traag was, niet welke regel code dat veroorzaakte.
Twee gevolgen die vaak voor verwarring zorgen
Groen scoren in het lab en rood in het veld kan dus prima, doordat je bezoekers gemiddeld op tragere toestellen zitten dan de simulatie aanneemt. En een pagina met te weinig bezoekers heeft helemaal geen veldgegevens; dan valt het rapport terug op de groep, precies zoals hierboven beschreven.
De werkverdeling is daarmee vanzelfsprekend: gebruik het lab om te zoeken waar het zit, gebruik het veld om vast te stellen of het opgelost is
Wie het omdraait, optimaliseert een simulatie.
Wat het 75e percentiel betekent voor jouw pagina
Google beoordeelt niet je gemiddelde bezoeker maar je 75e percentiel. Zet alle paginaweergaven van de afgelopen 28 dagen op volgorde van snelst naar traagst en pak de weergave op driekwart van die rij: dat is de waarde die geldt. Drie op de vier bezoekers hadden het dus beter of gelijk, een op de vier had het slechter.
Dat is een bewuste keuze en geen willekeur
Een gemiddelde laat zich optrekken door een grote groep snelle bezoekers, en juist daardoor verdwijnt de staart waar het probleem zit. Het 75e percentiel dwingt je om naar die trage kwart te kijken, want zolang die traag is haal je de drempel niet, hoe snel de rest ook is.
Daar volgt iets uit dat veel mensen verrast: je snelste bezoekers helpen je niet
Een pagina die al binnen een seconde laadt nog eens tweehonderd milliseconden versnellen verandert je 75e percentiel niet. De winst zit in de trage kwart, en die bestaat meestal uit een herkenbare groep: oudere Android-toestellen, mobiel netwerk buiten de bebouwde kom, en het eerste bezoek van iemand die nog niets in cache heeft staan.
Test dus niet alleen op je eigen glasvezel met een nieuwe laptop, want dan meet je de kant van de rij die toch al goed zit
Zet in de ontwikkelaarstools van je browser de snelheidsbeperking aan, kies een langzame verbinding en een beperkte processor, en herlaad met een lege cache. Dat komt niet exact overeen met je werkelijke bezoekers, maar het brengt je in de buurt van de kant waar het cijfer vandaan komt.
Let ten slotte op dat mobiel en desktop apart worden beoordeeld
Een pagina kan op desktop ruim binnen de drempel blijven en op mobiel er ver overheen gaan. Kijk dus altijd naar het mobiele blok eerst, want daar zit bij de meeste sites het merendeel van het bezoek.
LCP ontleed: vier stukken tijd, vier soorten werk
Van de drie meetwaarden is LCP het vaakst het probleem, en ook het vaakst verkeerd aangepakt. Dat komt doordat mensen LCP als een enkel getal behandelen terwijl het een optelsom is. Google knipt die optelsom in vier stukken die na elkaar gebeuren, en per stuk is het werk totaal verschillend. De opdeling staat in de uitleg van Google over het optimaliseren van LCP, gecontroleerd op 25 augustus 2026.
Het eerste stuk is de wachttijd op je server: hoe lang het duurt voordat de browser de eerste byte binnenkrijgt
Dat is hosting, caching en de snelheid waarmee je database antwoordt. Het tweede stuk is de vertraging voordat het laden begint: de tijd tussen die eerste byte en het moment waarop de browser doorheeft dat er een afbeelding of lettertype nodig is. Dat stuk loopt op wanneer het element pas via een stylesheet of via JavaScript bekend wordt in plaats van gewoon in de HTML te staan.
Het derde stuk is het downloaden zelf, en dat is het enige stuk waar comprimeren echt over gaat
Het vierde stuk is de rendervertraging: het bestand is binnen, maar het staat nog niet op het scherm omdat er nog blokkerende CSS of JavaScript voor in de rij staat.
INP en CLS komen ergens anders vandaan
INP heeft niets met laden te maken en alles met reageren. Ook die waarde valt uiteen, en wel in drie stukken: de invoervertraging voordat de browser aan je tik toekomt, de verwerkingstijd van de code die eraan hangt, en de presentatievertraging voordat het resultaat op het scherm staat. Die opdeling staat in de uitleg van Google over het optimaliseren van INP, gecontroleerd op 25 augustus 2026.
In de praktijk zit het probleem bijna altijd bij het eerste stuk, en de oorzaak is bijna altijd dezelfde: de browser is bezig met iets anders
Een script van derden dat op dat moment draait, een grote lap JavaScript die in een keer wordt uitgevoerd, een chatwidget die zichzelf aan het opbouwen is. Zolang die taak loopt kan de browser niets met je tik doen, en de bezoeker ziet niets gebeuren.
Nog iets om te weten: INP kijkt niet naar je eerste klik maar naar de traagste interactie van het bezoek, waarbij op pagina's met heel veel interacties een enkele uitschieter buiten beschouwing blijft. Een menu dat negen van de tien keer soepel opengaat en de tiende keer blijft hangen, is dus wel degelijk je INP. Zoek daarom niet naar wat gemiddeld traag is maar naar wat af en toe hapert.
CLS is de enige van de drie die je met het blote oog ziet, en de oorzaken zijn goed bekend
Google noemt onder meer: afbeeldingen en video's zonder bekende afmetingen, lettertypen die groter of kleiner uitvallen dan het reservelettertype, advertenties en widgets van derden die zichzelf onderweg groter maken, bronnen die asynchroon binnenkomen terwijl de bezoeker al leest, en inhoud die dynamisch boven bestaande inhoud wordt geschoven. De opsomming staat in de uitleg van Google over Cumulative Layout Shift, gecontroleerd op 25 augustus 2026.
De reparatie is bij CLS meestal het goedkoopst van de drie
Zet breedte en hoogte op elke afbeelding, reserveer een vaste hoogte voor je cookiebalk en je banners, en laat je lettertypen wisselen op een manier die geen sprong veroorzaakt. Je test het door op een telefoon met lege cache langzaam naar beneden te scrollen en te kijken of er iets onder je duim wegschuift.
Tot slot een grens die het benoemen waard is
Deze drie waarden gaan over de ervaring van je bezoeker en niet over de vraag of je pagina antwoord geeft op wat er gezocht werd. Een pagina die in een halve seconde laadt en de vraag niet beantwoordt, blijft een pagina die de vraag niet beantwoordt. Snelheid opent de deur, de inhoud doet het werk erachter, en dat deel staat in de kennisbank.
Veelgestelde vragen
Beoordeelt Google Core Web Vitals per pagina of sitebreed?
Per pagina. Search Console toont ze in groepen van pagina's met een vergelijkbare ervaring, en bij te weinig gegevens in een groep voor je hele domein. Zie je daar een rode groep, dan zoek je de traagste URL in die groep. Google heeft nooit een sitebrede Core Web Vitals-score aangekondigd.
Hoeveel impact hebben Core Web Vitals op mijn rankings?
Core Web Vitals zijn niet de belangrijkste rankingfactor. Ze wegen mee, en dat weegt het zwaarst wanneer de concurrentie op inhoud aan elkaar gewaagd is. Een aantal posities noemen we er niet bij: dat verschilt per zoekterm en niemand kan het vooraf uitrekenen, wij ook niet.
Moet ik al mijn oude pagina's verwijderen?
Nee. Verwijder alleen pagina's die slecht presteren en weinig verkeer opleveren. Pagina's die wel verkeer trekken, verbeter je.
Hoe snel zie ik resultaat?
Google baseert Core Web Vitals op 28 dagen gebruikersdata. Reken dus op minimaal vier weken voordat een verbetering zichtbaar kan zijn in het rapport, want zo lang duurt het voor het meetvenster is doorgeschoven. Wanneer je posities daarop reageren is niet te voorspellen: dat hangt ook af van alles wat je concurrenten in diezelfde weken doen.
Kan TheSEO helpen?
Ja. We voeren een volledige analyse uit, identificeren je probleempagina's en leveren een concreet actieplan met prioriteiten. Bekijk onze aanpak op SEO verbeteren of duik zelf verder in de kennisbank.
Als je niet weet welk stuk van FIG.03 jouw probleem is
Het lastigste aan Core Web Vitals is niet het repareren maar het aanwijzen. Zolang je niet weet of je verlies in de servertijd zit, in de ontdekking van je hero-afbeelding of in een script dat de render blokkeert, betaal je voor werk dat je cijfer niet beweegt. Nieuwe hosting kopen terwijl het probleem in stuk 04 zit is de duurste manier om niets op te lossen.
Zelf beginnen kan meteen: draai je traagste pagina door de meter voor Core Web Vitals en leg de uitkomst naast de vier stukken uit FIG.03. Zie je daarna nog steeds niet welk stuk de tijd opsoupeert, of levert je Search Console een rode groep op waarvan je de veroorzakende URL niet vindt, leg het dan een keer voor.
Via contact plannen we een gesprek van een half uur waarin we je rapport, je traagste drie URL's en je huidige hosting naast elkaar leggen. Je hoort daarna welk stuk je het eerst moet aanpakken en wat dat ongeveer kost, ook als dat antwoord is dat je er zelf uitkomt. Loopt het breder dan snelheid alleen, dan pakken wij het op als onderdeel van SEO verbeteren.