Core Web Vitals zijn drie metingen waarmee Google de ervaring van echte bezoekers beoordeelt: hoe snel de hoofdinhoud verschijnt (LCP), hoe snel de pagina op een klik reageert (INP) en hoeveel de inhoud verspringt (CLS). Je verbetert ze in een vaste volgorde: in Search Console kijken welke metriek faalt, per metriek de oorzaak opsporen en die in het template herstellen.
Reken op vier weken voordat Google een fix terugziet; waarom, staat bij de veelgestelde vragen.
Dit artikel gaat over meten, de oorzaak vinden en de aanpak per metriek. De volledige lijst ingrepen (server, afbeeldingen, fonts, scripts, caching) staat in website sneller maken: 12 ingrepen.
Wat zijn Core Web Vitals?
Core Web Vitals zijn de drie metrieken die Google gebruikt om laadsnelheid, reactiesnelheid en visuele stabiliteit van een pagina te meten bij echte Chrome-bezoekers. Elke metriek meet een ander moment van het bezoek en heeft een eigen grens voor 'goed'. Een pagina slaagt alleen als alle drie goed zijn.
| Metriek | Meet | Goed | Verbetering nodig | Slecht |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Wanneer het grootste zichtbare element getekend is | ≤ 2,5 s | 2,5-4,0 s | > 4,0 s |
| INP (Interaction to Next Paint) | Hoe snel de pagina zichtbaar reageert op klikken, tikken en typen | ≤ 200 ms | 200-500 ms | > 500 ms |
| CLS (Cumulative Layout Shift) | Hoeveel de inhoud onverwacht verspringt | ≤ 0,1 | 0,1-0,25 | > 0,25 |
De grenzen gelden voor het 75e percentiel van alle paginabezoeken, apart voor mobiel en desktop (bron: web.dev, Core Web Vitals-drempels). Een kwart van de paginabezoeken mag dus trager zijn; de rest moet onder de grens blijven.
Sinds 12 maart 2024 bestaan de Core Web Vitals van Google uit LCP, INP en CLS; INP verving toen First Input Delay (web.dev). De drempels staan nog steeds op deze waarden (Google Search Central, bijgewerkt 10 december 2025).
Core Web Vitals check: zo vind je wat faalt
Een check begint in Search Console, niet in een snelheidstest. Daar zie je welke groep pagina's faalt en op welke metriek, gemeten bij je eigen bezoekers.
- Open het rapport Core Web Vitals in Search Console. Begin bij mobiel en kies de URL-groep met de meeste URL's in 'Slecht'.
- Lees welke metriek faalt. Een groep krijgt de status van zijn slechtste metriek, dus één rode CLS maakt de hele groep rood.
- Neem één voorbeeld-URL en zoek de oorzaak. Gebruik PageSpeed Insights en het Performance-paneel van Chrome DevTools; per metriek staat hieronder waar je kijkt.
- Herstel de oorzaak in het template, niet per pagina. URL's in één groep delen meestal dezelfde opbouw, dus één fix herstelt de hele groep.
- Controleer in het lab en zet de wijziging live. Een labtest bevestigt dat de oorzaak weg is; het oordeel van Google komt pas uit de velddata.
- Klik op 'Bijhouden starten'. Search Console volgt de groep dan 28 dagen. Noteer de datum van je wijziging, zodat je een daling later aan de juiste fix koppelt.
De groepering, de regel van de slechtste metriek en de controlesessie van 28 dagen staan in de Search Console-help over het Core Web Vitals-rapport. Heeft een groep te weinig data, dan valt Search Console terug op een groep voor je hele oorsprong (bijvoorbeeld https://www.jouwsite.nl).
Core Web Vitals test: waarom Lighthouse en Search Console verschillen
PageSpeed Insights toont bovenaan velddata en daaronder een Lighthouse-test. Dat zijn twee verschillende metingen, en ze kunnen elkaar tegenspreken.
- Velddata komt uit het Chrome User Experience Report (CrUX): echte Chrome-bezoekers over de afgelopen 28 dagen. Daarop is de Core Web Vitals-beoordeling (geslaagd of mislukt) gebaseerd.
- Labdata is één gesimuleerde laadbeurt onder vaste omstandigheden (mobiel: een middenklasse-telefoon op een mobiel netwerk; desktop: een vaste verbinding). Goed om te debuggen, maar geen oordeel van Google.
- INP ontbreekt in het lab. De standaard Lighthouse-test (ook die in PageSpeed Insights) meet alleen het laden; er klikt niemand. Total Blocking Time (TBT) is daar de benadering (web.dev, TBT).
Bron: Google, over PageSpeed Insights. Sinds Lighthouse 13 (oktober 2025) heten de verbeterpunten in het rapport 'insights', zoals 'LCP breakdown' (LCP-opsplitsing) en 'Layout shift culprits'; de score zelf wordt op dezelfde manier berekend (Chrome for Developers).
Wat de combinatie van uitslagen betekent
Onze beslistabel voor de volgende stap: de velddata geeft het oordeel, de labtest wijst de oorzaak aan.
| Velddata (Search Console, CrUX) | Labtest (Lighthouse) | Wat het meestal betekent | Volgende stap |
|---|---|---|---|
| Goed | Goed | Niets aan de hand | Niets doen; besteed je tijd aan content |
| Goed | Slecht | Je echte bezoekers hebben snelle toestellen of hebben de pagina al eerder geladen | Geen haast; houd de velddata in de gaten na grote wijzigingen |
| Slecht op INP of CLS | Goed | Het probleem zit in klikken of scrollen, wat de labtest niet doet | Zelf klikken en scrollen met het Performance-paneel open |
| Slecht op LCP | Goed | Echte omstandigheden zijn zwaarder: trage server onder drukte, cookiebanner, advertenties | LCP-opsplitsing bekijken op een gewone telefoon |
| Slecht | Slecht | Het probleem zit in het template zelf | De insight van de falende metriek volgen |
Waar je kijkt
- Search Console, rapport Core Web Vitals: groepen vergelijkbare URL's, apart voor mobiel en desktop. Hier begin je.
- PageSpeed Insights: velddata per URL of per oorsprong, plus een Lighthouse-diagnose met het LCP-element en de verspringende elementen. Een snelle Core Web Vitals test van één URL doe je in PageSpeed Insights.
- Chrome DevTools, Performance-paneel: toont je eigen LCP, CLS en INP live terwijl je de pagina gebruikt, en kan die naast de CrUX-cijfers van je echte bezoekers zetten (Chrome DevTools-documentatie).
- De web-vitals-bibliotheek: een klein script van Google waarmee je LCP, INP en CLS bij je eigen bezoekers meet en naar je analytics stuurt.
Welke van die instrumenten gratis zijn en wat elk ervan wel en niet laat zien, staat in ons overzicht van gratis SEO-tools.
Wat is LCP (Largest Contentful Paint)?
LCP is de tijd vanaf het openen van de pagina tot het grootste zichtbare element in beeld getekend is. Goed is 2,5 seconden of minder. Dat element is meestal een hero-afbeelding of een grote kop, maar kan ook een video, een achtergrondafbeelding of een lange alinea zijn (web.dev, LCP).
Browsers slaan elementen over die geen echte inhoud zijn: onzichtbare elementen, een achtergrond die het hele scherm vult en wazige placeholders. Een cookiebanner met veel tekst telt wel mee en kan op mobiel het LCP-element zijn (web.dev, cookiemeldingen).
Hoe verbeter je LCP?
Zoek eerst welk onderdeel van de LCP te lang duurt, voordat je iets aanpast. web.dev splitst LCP op in vier fasen, elk met een richtaandeel (web.dev, LCP optimaliseren).
| Fase | Wat het is | Richtaandeel (web.dev) | Typische oorzaak |
|---|---|---|---|
| Time to First Byte | Tot de eerste byte HTML binnen is | ca. 40% | Trage server, geen page caching, redirects |
| Laadvertraging | Van eerste byte tot de browser het LCP-bestand begint te laden | < 10% | Afbeelding via CSS, JavaScript of een slider; lazy-load op de hero |
| Laadduur | Het downloaden van het LCP-bestand zelf | ca. 40% | Te zwaar bestand, verkeerd formaat of maat |
| Rendervertraging | Van bestand binnen tot element getekend | < 10% | Blokkerende CSS, fonts of scripts |
In PageSpeed Insights en DevTools zie je deze LCP-opsplitsing in de insight 'LCP breakdown', samen met het element dat als LCP telt.
Rekenvoorbeeld (fictief): een LCP van 3,4 s met 0,5 s TTFB, 1,9 s laadvertraging, 0,6 s laadduur en 0,4 s rendervertraging. Een snellere server of kleiner bestand helpt hier weinig; de winst zit in de laadvertraging. Typische oorzaak: de hero-afbeelding heeft lazy-load of wordt pas via een script ingeladen.
Drie beslisregels uit dezelfde web.dev-gids die de meeste laadvertraging wegnemen:
- Nooit lazy-load op de LCP-afbeelding. Dat geeft altijd onnodige laadvertraging.
- fetchpriority="high" op de afbeelding die waarschijnlijk LCP is. De browser haalt hem dan vóór minder belangrijke bestanden op.
- Preload alleen als de browser het bestand laat ontdekt, bijvoorbeeld een achtergrondafbeelding uit CSS; staat het als <img> in de HTML, dan vindt de browser het zelf al.
De oplossingen per fase (caching, AVIF/WebP, fonts) werk je af met de ingrepen in website sneller maken.
Wat is INP (Interaction to Next Paint)?
INP meet hoe lang het duurt voordat de pagina zichtbaar reageert op een klik, tik of toetsaanslag. Goed is 200 milliseconden of minder. Met de muis over iets bewegen, zoomen en scrollen tellen niet mee (web.dev, INP).
INP kijkt naar de traagste interactie van een bezoek, niet naar de eerste. Alleen bij pagina's met veel interacties negeert de berekening één uitschieter per 50 interacties. Eén trage knop op een productfilter kan dus de score van de hele pagina bepalen.
Elke interactie bestaat uit drie delen (web.dev, INP optimaliseren):
- Invoervertraging: de browser is nog bezig met iets anders en kan je klik niet meteen oppakken.
- Verwerkingstijd: de code die op de klik reageert, draait.
- Presentatievertraging: de browser rekent de opmaak opnieuw uit en tekent het nieuwe beeld.
Hoe vind je de trage interactie?
- Klik door de pagina met het Performance-paneel open; het toont INP live per interactie.
- Neem een opname rond de trage klik en zoek lange taken (long tasks): taken langer dan 50 ms, rood gemarkeerd.
- Kijk van wie het script is: chatwidgets, tag managers, A/B-tools en zware sliders zijn de gebruikelijke verdachten, naast je eigen code.
- Test met CPU-vertraging aan of op een gewone telefoon; een snelle laptop verbergt het probleem.
Hoe verbeter je INP?
- Lange taken opknippen, zodat de browser tussendoor op een klik kan reageren (web.dev noemt dit 'yielden': de browser even voorrang geven).
- Eerst de zichtbare reactie tonen, het overige werk (tracking, opslaan) daarna.
- Scripts van derden later of pas na interactie laden, of weghalen als niemand de data nog gebruikt.
- Minder HTML-elementen op de pagina (de DOM): bij duizenden elementen wordt elke herberekening van de opmaak trager.
Voorbeeld (fictief): een klik op een filterknop duurt 420 ms. In de opname zie je 300 ms verwerkingstijd, waarvan 250 ms in een tag die bij elke klik vijf analytics-events verstuurt. Toon eerst de gefilterde producten en stuur de events daarna: de verwerkingstijd valt dan grotendeels weg en de interactie komt onder 200 ms.
Voor het opknippen is scheduler.yield() de nette route. Die werkt in Chrome en Edge vanaf versie 129 en Firefox vanaf 142, niet in Safari; daar val je terug op setTimeout (web.dev, lange taken optimaliseren). Dit is werk voor een developer of je thema-leverancier, niet voor een plugin.
Wat is CLS (Cumulative Layout Shift)?
CLS meet hoeveel zichtbare inhoud onverwacht verspringt terwijl iemand de pagina gebruikt. Goed is 0,1 of minder. Het getal heeft geen eenheid: het combineert hoeveel van het scherm verschuift met hoe ver het verschuift (web.dev, CLS).
Het voorbeeld van web.dev: een blok dat de helft van het scherm vult, zakt een kwart schermhoogte. Het geraakte deel is 0,75 van het scherm, de afstand 0,25, de score 0,75 × 0,25 = 0,19. Eén zo'n verspringing zet een pagina dus al in 'verbetering nodig'.
Verschuivingen die minder dan 1 seconde na elkaar komen, tellen samen tot een venster van maximaal 5 seconden; het zwaarste venster is je score. Verschuivingen binnen 500 ms na een klik, tik of toetsaanslag tellen niet mee. Een menu dat opent als je erop klikt, is dus geen probleem; een balk die uit zichzelf verschijnt wel.
Hoe verbeter je CLS?
Zoek de oorzaak in deze vier, in deze volgorde:
- Afbeeldingen of video's zonder width en height.
- Banners, meldingen of advertenties die boven bestaande inhoud worden ingevoegd.
- Webfonts met een andere breedte dan het fallback-font.
- Embeds (kaarten, video, social posts) zonder gereserveerde ruimte.
De insight 'Layout shift culprits' in PageSpeed Insights en DevTools wijst de verspringende elementen en hun waarschijnlijke oorzaak aan. De fix is ruimte reserveren: vaste maten, een minimale hoogte voor de banner of de embed.
Wie lost wat op?
Niet elke fix vraagt een developer. Een vuistregel voor wie een melding oppakt:
| Oorzaak | Metriek | Wie pakt het op |
|---|---|---|
| Te zware hero-afbeelding, embed zonder vaste maat | LCP, CLS | Wie de content beheert, in het CMS |
| Chatwidget, A/B-tool of tag die niemand meer gebruikt | INP, soms LCP | Wie de tag manager beheert |
| Lazy-load op de hero, cookiebanner die inhoud wegduwt | LCP, CLS | Thema-instelling of developer |
| Lange taken in eigen JavaScript, grote DOM | INP | Developer |
| Trage server, geen page caching | LCP | Hosting of developer |
Draait je site op WordPress, dan zitten thema en plugins vaak in meerdere rijen tegelijk; daarvoor is er WordPress SEO met snelheid en plugin-stack. Ligt het bij de developer- of hostingrijen, dan pakken we het op in ons traject technische SEO: meten per template, de oorzaak herstellen en de velddata volgen tot de groep groen is.
Fouten die een groep rood houden
- Een groene labtest als bewijs zien. De labtest bevestigt dat de oorzaak weg is; of de groep slaagt, beslist de velddata.
- De verkeerde metriek aanpakken. Afbeeldingen verkleinen helpt niet als CLS of INP de groep rood maakt.
- Gokken op de fase. Zonder de LCP-opsplitsing optimaliseer je de server terwijl de laadvertraging het probleem kan zijn.
- Per pagina repareren. Je herstelt één URL en de rest van de groep blijft rood.
- Na twee dagen conclusies trekken. Oude bezoeken tellen nog weken mee.
Zijn Core Web Vitals een rankingfactor?
Ja, maar relevantie weegt zwaarder. Google schrijft dat Core Web Vitals worden gebruikt door de rankingsystemen, en ook dat Google Search altijd de meest relevante inhoud probeert te tonen, zelfs als de pagina-ervaring minder is (Google Search Central, pagina-ervaring, bijgewerkt 22 september 2026). Goede resultaten in het Core Web Vitals-rapport garanderen volgens dezelfde pagina geen toppositie.
Reken er dus niet op dat groene scores je van pagina twee naar één tillen. Onze beslisregel: rood op een template met veel verkeer of veel omzet pak je aan; oranje op een blogarchief laat je liggen zolang er content te schrijven is.
Waar snelheid past tussen indexatie, structured data en de rest, lees je in wat technische SEO is. Levert geen enkele fix iets op, dan is het thema of de paginabouwer de rem; dat behandelt de slotsectie van het artikel over website sneller maken.
Veelgestelde vragen
Wat betekent een mislukte Core Web Vitals-beoordeling in PageSpeed Insights?
Dat minstens één van de drie metrieken bij het 75e percentiel van je echte bezoekers niet 'goed' is. Kijk welke metriek rood of oranje is; die pak je als eerste aan. Het Lighthouse-cijfer eronder staat daar los van.
Waarom is Lighthouse groen en Search Console rood?
De Lighthouse-test in PageSpeed Insights test één laadbeurt onder vaste omstandigheden en meet geen INP. Search Console kijkt naar 28 dagen echte bezoekers, met trage telefoons, slechte verbindingen en klikken. Het omgekeerde kan ook: een rode labtest terwijl je echte bezoekers een goede ervaring hebben.
Mijn site heeft geen velddata. Wat nu?
CrUX neemt alleen openbare, indexeerbare pagina's op met genoeg Chrome-bezoek. PageSpeed Insights valt dan terug op cijfers voor je hele oorsprong (alle pagina's op https://www.jouwsite.nl). Heeft ook die te weinig bezoek, dan zijn er geen veldcijfers. Meet dan zelf met de web-vitals-bibliotheek en gebruik labdata als richting.
Hoe lang duurt het voordat Search Console de verbetering ziet?
Velddata beslaat 28 dagen, dus de oude, tragere bezoeken tellen nog weken mee. De controlesessie na 'Bijhouden starten' loopt ook 28 dagen. Reken op minstens vier weken na livegang, vaak iets langer, voordat de groep groen is.
Moet ik een PageSpeed-score van 100 halen?
Nee. Het doel is dat alle drie de Core Web Vitals in de velddata 'goed' zijn. Een labscore van 80 met groene velddata is beter dan 100 in het lab met rode velddata.
Telt First Input Delay (FID) nog mee?
Nee. Bij de Core Web Vitals van Google heeft INP op 12 maart 2024 FID vervangen. Tools en artikelen die nog FID tonen of uitleggen hoe je 'FID verbetert', zijn verouderd.
Is mobiel of desktop belangrijker?
Search Console beoordeelt beide apart. Begin met mobiel: daar zijn toestellen en verbindingen trager, dus daar zitten de meeste problemen. Een fix in het template verbetert meestal beide.
Heb ik een developer nodig om Core Web Vitals te verbeteren?
Voor afbeeldingen, embeds en overbodige tags meestal niet; die los je op in het CMS of de tag manager. Voor INP-problemen in eigen JavaScript, lazy-load in het thema of een trage server wel. Zie de tabel 'Wie lost wat op?' hierboven.
Helpen betere Core Web Vitals om in AI Overviews te komen?
Google noemt geen aparte eisen voor AI Overviews of AI Mode; een goede pagina-ervaring hoort bij dezelfde basis als voor gewone resultaten (Google Search Central, AI-functies). Of je wordt geciteerd, hangt vooral af van of je pagina de vraag het best beantwoordt.