Core Web Vitals zijn drie prestatiemetingen die bepalen hoe goed je website presteert. Google gebruikt ze als ranking factor sinds 2021. Dat betekent: trage sites zakken in de zoekresultaten.
Maar het gaat niet alleen om rankings. Core Web Vitals meten de échte gebruikservaring. Snelheid, responsiviteit, en stabiliteit tijdens het laden.
In deze gids leg ik uit wat Core Web Vitals zijn, hoe je ze meet, en vooral: hoe je ze verbetert.
Wat zijn core web vitals precies
Core Web Vitals zijn drie specifieke metingen die Google heeft geselecteerd uit tientallen performance metrics. Ze focussen op wat gebruikers daadwerkelijk ervaren.
Het gaat om real-world data. Niet lab-testen, maar metingen van echte bezoekers op echte apparaten met echte internetverbindingen.
De drie metrics zijn: Largest Contentful Paint (LCP), First Input Delay (FID), en Cumulative Layout Shift (CLS). Elk meet een ander aspect van gebruikservaring.
Dit is waarom ze belangrijk zijn: ze correlen direct met bounce rate, conversie, en user engagement. Betere scores betekenen betere business resultaten.
Largest Contentful Paint: laadsnelheid
LCP meet hoe snel het grootste zichtbare element op je pagina laadt. Dit is meestal een hero image, video, of groot tekstblok boven de vouw.
Google’s drempelwaarden zijn duidelijk: onder 2,5 seconden is goed. Tussen 2,5 en 4 seconden moet beter. Boven 4 seconden is slecht.
Zo werkt het: de browser registreert wanneer het grootste element volledig gerenderd is. Dat moment is je LCP.
Welk element telt als “largest” kan veranderen tijdens het laden. Als eerst een heading verschijnt en dan een grote image, telt die image.
LCP meet alleen elementen binnen de viewport. Content onder de vouw telt niet mee voor deze metric.
Waarom LCP vaak slecht scoort
De meeste LCP problemen komen door te grote images. Een hero image van 3MB laadt niet binnen 2,5 seconden op mobiel.
Render-blocking resources zijn een andere boosdoener. CSS en JavaScript die voor de pagina laden vertragen de LCP.
Trage server response time (TTFB) heeft direct impact op LCP. Als je server 2 seconden doet over antwoorden, blijft er weinig tijd over.
Client-side rendering vertraagt LCP significant. De browser moet eerst JavaScript downloaden, parsen, en uitvoeren voordat content verschijnt.
First Input Delay: interactiviteit
FID meet de tijd tussen de eerste gebruikersinteractie en het moment dat de browser kan reageren. Denk aan klikken, tikken, of typen.
Doel: onder 100 milliseconden. Tussen 100 en 300 ms moet beter. Boven 300 ms voelt traag aan.
Deze metric meet alleen de eerste interactie. Dat is het moment waarop gebruikers vaak afhaken als de site niet reageert.
Let op: FID meet alleen de delay, niet de tijd die de actie zelf kost. Het gaat om hoe snel de browser kan beginnen met reageren.
Waarom FID hoog is
De hoofdoorzaak is JavaScript execution op de main thread. Als de browser druk is met scripts, kan hij niet reageren op gebruikers.
Lange taken blokkeren de main thread. Elke JavaScript task die langer dan 50ms duurt creëert een window waarin geen interactie mogelijk is.
Third-party scripts zijn vaak de schuldige. Analytics, advertenties, en chat widgets draaien allemaal op de main thread.
De overgang naar INP
Belangrijk om te weten: Google vervangt FID door Interaction to Next Paint (INP) in maart 2024. INP meet álle interacties, niet alleen de eerste.
Het principe blijft hetzelfde: hoe snel reageert je site op gebruikersacties. Maar INP is een strengere meting.
Cumulative Layout Shift: visuele stabiliteit
CLS meet hoeveel elementen verspringen tijdens het laden. Denk aan tekst die ineens omlaag schiet omdat er een image laadt.
De score is een getal zonder eenheid. Onder 0,1 is goed. Tussen 0,1 en 0,25 moet beter. Boven 0,25 is slecht.
Zo wordt het berekend: voor elk element dat verspringt berekent Google het percentage van de viewport dat beweegt, vermenigvuldigd met de afstand.
Dit is waarom het belangrijk is: onverwachte layout shifts zijn frustrerend. Je probeert te klikken en de button springt weg.
Veelvoorkomende CLS veroorzakers
Images zonder dimensies zijn de nummer één oorzaak. De browser weet niet hoeveel ruimte te reserveren tot de image geladen is.
Webfonts die late laden veroorzaken FOIT (Flash of Invisible Text) of FOUT (Flash of Unstyled Text). Tekst verspringt als het font wordt vervangen.
Dynamically injected content boven bestaande content duwt alles omlaag. Denk aan cookie banners of advertenties die ineens verschijnen.
Animations en transitions kunnen ook CLS veroorzaken als ze niet goed worden geïmplementeerd.
Hoe meet je core web vitals
Er zijn twee soorten data: lab data en field data. Beide zijn belangrijk maar vertellen een ander verhaal.
Lab data komt van gecontroleerde testen in een gesimuleerde omgeving. Het is consistent en reproduceerbaar maar niet altijd realistisch.
Field data komt van echte gebruikers. Het is realistisch maar varieert per gebruiker, apparaat, en verbinding.
Google PageSpeed Insights
PageSpeed Insights combineert beide datatypen. Het toont lab data van Lighthouse én field data van het Chrome User Experience Report.
Zo gebruik je het: voer je URL in en bekijk eerst de field data sectie. Dit is wat Google gebruikt voor rankings.
De lab data sectie geeft specifieke aanbevelingen. Gebruik die om problemen te identificeren en op te lossen.
Let op kleuren: groen is goed, oranje moet beter, rood is slecht. Focus eerst op de rode items.
Google Search Console
Search Console heeft een dedicated Core Web Vitals rapport onder “Experience”. Het toont trends over tijd voor je hele site.
URLs worden geclusterd als “good”, “needs improvement”, of “poor”. Klik op een cluster om te zien welke URLs er in zitten.
De data is gebaseerd op 28 dagen real user measurements. Het kan dus een maand duren voordat verbeteringen zichtbaar zijn.
Chrome DevTools en Lighthouse
Voor development is Lighthouse in Chrome DevTools onmisbaar. Open DevTools, ga naar Lighthouse tab, en run een audit.
Dit geeft je instant feedback tijdens development. Test op zowel desktop als mobile device emulation.
De Performance tab in DevTools laat je precies zien wat er gebeurt tijdens het laden. Gebruik het om bottlenecks te identificeren.
LCP verbeteren: concrete acties
Optimaliseer je largest contentful paint element. Meestal is dit een hero image of banner.
Image optimalisatie
Gebruik moderne formaten zoals WebP of AVIF. Deze comprimeren beter dan JPEG zonder kwaliteitsverlies.
Serveer responsive images met srcset. Mobiele gebruikers hoeven geen 4K desktop image te downloaden.
Lazy-load images onder de vouw. Maar let op: lazy-load NOOIT je LCP element. Dat maakt het alleen maar trager.
Gebruik een CDN voor image delivery. Dit verkort de fysieke afstand tussen server en gebruiker.
CSS optimalisatie
Inline critical CSS rechtstreeks in de HTML. Dit zijn de styles die nodig zijn voor content boven de vouw.
Defer non-critical CSS met media queries of preload hints. Laat onderliggende styles later laden.
Minimaliseer en comprimeer alle CSS bestanden. Elke kilobyte telt.
JavaScript optimalisatie
Defer JavaScript waar mogelijk. Tenzij het nodig is voor de initial render, kan het later.
Code-split je bundles zodat alleen essentiële code vooraf laadt. De rest kan on-demand laden.
Gebruik async voor third-party scripts die niet critical zijn. Ze blokkeren dan niet de render.
Server optimalisatie
Verbeter je Time to First Byte. Gebruik server-side caching, database optimalisatie, en een goede hosting provider.
Implementeer HTTP/2 of HTTP/3. Deze protocollen laden resources sneller dan HTTP/1.1.
Gebruik preconnect voor externe resources. Dit bespaart DNS lookup en TLS handshake tijd.
FID en INP verbeteren
Focus op het vrijhouden van de main thread. Alle interactiviteit draait op deze single thread.
JavaScript execution optimaliseren
Break up long tasks in kleinere chunks. Gebruik setTimeout of requestIdleCallback om werk te spreaden.
Verwijder of defer third-party scripts die niet essentieel zijn. Elk script voegt processing time toe.
Gebruik web workers voor zware berekeningen. Deze draaien op een aparte thread en blokkeren de main thread niet.
Input delay reduceren
Minimaliseer JavaScript execution tijdens page load. Hoe minder de browser moet doen, hoe sneller hij kan reageren.
Gebruik event delegation in plaats van veel individuele event listeners. Dit reduceert memory gebruik en setup tijd.
Debounce en throttle event handlers voor scroll en resize events. Deze firen vaak en kunnen de thread overspoelen.
CLS verbeteren: layout stabiliteit
Reserveer ruimte voor elk element voordat het laadt. De golden rule voor goede CLS scores.
Image en video dimensies
Specificeer altijd width en height attributen op images en videos. Moderne browsers berekenen dan automatisch de aspect ratio.
Gebruik CSS aspect-ratio voor responsive containers. Dit houdt de ruimte correct zelfs als de afmetingen schalen.
Font optimalisatie
Gebruik font-display: optional voor webfonts. Als het font niet snel genoeg laadt, gebruikt de browser het fallback font.
Preload belangrijke webfonts met rel=”preload”. Dit zorgt dat ze early in het laadproces starten.
Match fallback fonts zo goed mogelijk met webfonts. Gebruik font-size, line-height, en letter-spacing aanpassingen.
Dynamische content
Reserveer ruimte voor ads, embeds, en andere dynamische content. Gebruik min-height op containers.
Inject nieuwe content nooit boven bestaande content. Gebruik append in plaats van prepend.
Animations moeten transform en opacity gebruiken. Deze properties triggeren geen layout shifts.
Tools en monitoring
Continue monitoring is essentieel. Core Web Vitals kunnen verslechteren door updates of nieuwe content.
Real User Monitoring (RUM)
Implementeer RUM met de web-vitals JavaScript library van Google. Dit stuurt metrics van echte gebruikers naar je analytics.
Tools zoals SpeedCurve, Calibre, of DebugBear bieden dedicated CWV monitoring met alerts.
Synthetic monitoring
Zet geautomatiseerde Lighthouse tests op met CI/CD. Catch performance regressies voordat ze live gaan.
Test vanaf verschillende locaties en netwerkcondities. Gebruikers in verschillende landen hebben verschillende ervaringen.
Veelgestelde vragen over Core Web Vitals
Hoe vaak update Google de Core Web Vitals data
Google gebruikt een 28-dagen rolling window voor field data. Je ziet veranderingen dus niet onmiddellijk na optimalisaties. Het kan 2-4 weken duren voordat verbeteringen volledig zichtbaar zijn in Search Console.
Tellen Core Web Vitals voor alle pagina’s even zwaar
Nee. Google evalueert je site per URL. Individuele pagina’s kunnen goed of slecht scoren. Focus eerst op je belangrijkste landing pages en hoogst bezochte content.
Moet ik perfecte scores hebben om goed te ranken
Nee. “Good” scores zijn voldoende. Het verschil tussen een LCP van 2,0 en 1,5 seconden heeft minimale ranking impact. Focus op het halen van de “good” drempels, niet op perfectie.
Werken Core Web Vitals hetzelfde op mobile en desktop
Google gebruikt voornamelijk mobile data voor rankings sinds mobile-first indexing. Desktop scores tellen mee maar mobile is belangrijker. Test en optimaliseer altijd mobile eerst.
Kan JavaScript frameworks zoals React goede scores halen
Ja, maar het vereist extra aandacht. Server-side rendering of static generation helpen enorm. Pure client-side rendering maakt goede LCP scores lastig. Frameworks zoals Next.js maken het makkelijker.
Hebben external scripts altijd negatieve impact op scores
Niet altijd, maar vaak wel. Scripts die async of defer laden en weinig werk doen hebben minimale impact. Zware analytics suites, tag managers, en ad networks kunnen scores significant verslechteren. Audit regelmatig welke scripts echt nodig zijn.
Praktijkvoorbeelden: voor en na optimalisatie
Een e-commerce site verbeterde hun LCP van 4,2 naar 1,8 seconden door hun hero image van 2,5MB te comprimeren naar 180KB WebP. Dit leidde tot 23% minder bounces op product pages.
Een nieuwssite loste hun FID problemen op door third-party ad scripts te optimaliseren. Ze gingen van 380ms naar 85ms delay. Het resultaat: 15% meer clicks op artikelen.
Een SaaS bedrijf had CLS scores van 0,35 door dynamische testimonials. Door vaste hoogte containers te gebruiken kwam de score naar 0,05. Conversie steeg met 12%.
Deze voorbeelden laten zien: betere Core Web Vitals scores correlen direct met business metrics. Het is niet alleen voor Google rankings.
Veelgemaakte fouten bij optimalisatie
Over-optimalisatie van metrics ten koste van functionaliteit. Bijvoorbeeld: alle JavaScript verwijderen geeft perfecte scores maar breekt je site.
Alleen focussen op lab data. Field data is wat telt voor rankings. Test met echte gebruikersdata, niet alleen Lighthouse.
Lazy-loading van LCP elements. Dit is contraproductief. Je grootste element moet juist zo snel mogelijk laden.
Negeren van mobile performance. Desktop kan perfect scoren terwijl mobile dramatisch is. Test altijd beide.
De toekomst van Core Web Vitals
Google blijft de metrics evolueren. INP vervangt FID omdat het een completere meting is van responsiveness.
Nieuwe metrics kunnen worden toegevoegd. Google experimenteert met smoothness metrics en andere UX indicators.
De drempelwaarden kunnen strenger worden naarmate het web sneller wordt. Wat vandaag “goed” is kan over twee jaar “gemiddeld” zijn.
Blijf op de hoogte van updates via de web.dev vitals documentatie. Google communiceert wijzigingen maanden van tevoren.
Start vandaag met verbeteren
Core Web Vitals zijn niet optioneel meer. Ze beïnvloeden rankings, user experience, en conversie.
Begin met meten. Open Search Console en check je huidige status. Identificeer je slechtst scorende pagina’s.
Focus op quick wins eerst. Image compressie en optimalisatie levert vaak de snelste resultaten.
Monitor continu. Performance is geen one-time project maar een ongoing proces.
Wil je hulp bij het optimaliseren van jouw Core Web Vitals? Neem contact op voor een gratis performance audit van je site.
Erwin Verbeek is SEO- en GEO-specialist en oprichter van Online Ambition. Meer over Erwin
