De Core Web Vitals zijn de drie metingen waarmee Google meet hoe een pagina aanvoelt: hoe lang het duurt voordat de hoofdinhoud verschijnt (LCP), hoe snel de pagina reageert als je erop tikt (INP) en hoeveel ze verschuift tijdens het laden (CLS). Een pagina slaagt als bij 75% van de echte bezoeken (apart gemeten op mobiel en desktop) alle drie de metingen in de kolom ‘Goed’ vallen (web.dev):
| Meting | Goed | Kan beter | Slecht |
|---|---|---|---|
| LCP (laden) | tot 2,5 s | 2,5 tot 4 s | meer dan 4 s |
| INP (reactie) | tot 200 ms | 200 tot 500 ms | meer dan 500 ms |
| CLS (stabiliteit) | tot 0,1 | 0,1 tot 0,25 | meer dan 0,25 |
De afkortingen staan voor Largest Contentful Paint, Interaction to Next Paint en Cumulative Layout Shift. INP verving op 12 maart 2024 de oude FID (web.dev). Heeft een gids het nog over FID, dan is die verouderd.
Tellen ze mee voor je positie in Google?
Ja, maar ze bepalen niet alles. Google bevestigt dat zijn rankingsystemen de Core Web Vitals gebruiken en tegelijk dat het altijd de meest relevante inhoud probeert te tonen, ook als de paginabeleving tekortschiet (Google Search Central). Een snelle website maakt inhoud die niet aansluit bij de zoekvraag niet goed; tussen twee even nuttige pagina’s helpt ze wel.
Het duidelijkst zie je snelheid terug in je bedrijfsresultaten. In een onderzoek dat Google liet uitvoeren door Deloitte en 55 bij 37 Europese en Amerikaanse merken, leverde een mobiele website die 0,1 s sneller was 8,4% meer conversies op voor webwinkels en 10,1% voor reissites; op sites voor leadgeneratie bereikten 21,6% meer gebruikers de pagina om het formulier te versturen (web.dev). De gegevens zijn van 2019 en gemeten met oudere metingen dan de huidige, maar voor webwinkels en reissites is de richting duidelijk.
Waar je de gegevens van je website ziet
- Veldgegevens, de gegevens die Google gebruikt: ze komen van echte bezoeken met Chrome (het CrUX-rapport). Je vindt ze in het rapport Core Web Vitals in Search Console, dat de laatste 28 dagen samenvat en vergelijkbare pagina’s groepeert (Search Console Help), en bovenaan in PageSpeed Insights. Krijgt je website weinig bezoeken, dan zijn er misschien nog geen gegevens.
- Labgegevens: een gesimuleerde test, zoals die van Lighthouse onderaan PageSpeed Insights. Ze helpen het probleem te vinden, maar zijn niet wat Google meet. De Lighthouse-test in PageSpeed Insights kan INP niet meten, omdat niemand de pagina tijdens de test gebruikt, en gebruikt daarom de Total Blocking Time (TBT) (web.dev).
Heb je iets opgelost, dan kun je in Search Console op ‘Bijhouden starten’ klikken: Google houdt die pagina’s 28 dagen in de gaten voordat het probleem als opgelost geldt.
Zo verbeter je elke meting
LCP: het belangrijkste eerst
- Vertraag de hoofdafbeelding niet. Nooit met lazy loading (
loading="lazy"), en liefst metfetchpriority="high", zodat de browser haar eerder opvraagt (web.dev). - Lichte afbeeldingen: in WebP of AVIF en niet groter dan het formaat waarin ze worden getoond.
- Een server die snel antwoordt en een contentnetwerk (CDN) dicht bij je bezoekers.
- De hoofdafbeelding in de HTML: voegt JavaScript haar pas later toe, dan vindt de browser haar niet op tijd.
INP: een pagina die meteen reageert
- Minder JavaScript, en wat overblijft opgedeeld in korte taken: zolang de browser een lange taak uitvoert, kan hij niet op een tik reageren (web.dev).
- Bekijk scripts van derden kritisch, zoals chats, advertentiepixels of widgets: ze vechten allemaal om dezelfde thread.
- Reageer meteen met iets zichtbaars, al is het maar een ‘bezig met laden’, en doe het zware werk daarna.
- Een niet te grote pagina: hoe meer elementen, hoe meer werk elke wijziging de browser kost.
CLS: niets verschuift
- Breedte en hoogte op elke afbeelding en video (
widthenheight, ofaspect-ratioin CSS), zodat de browser de ruimte vrijhoudt (web.dev). - Houd ruimte vrij voor wat later komt: advertenties, ingesloten video’s of een melding die bovenaan verschijnt. Laat ze liever over de pagina zweven dan de inhoud naar beneden te duwen.
- Weblettertypen met een reservelettertype dat op hun maten is afgestemd (
size-adjust), zodat de tekst niet verspringt als het lettertype wisselt. - Animeer met
transform, niet doortopofleftte verplaatsen.
Zo doen we het bij Vetro
Onze eigen website is een 3D-ervaring, en snelheid hoort vanaf het begin bij het ontwerp:
- de tekst komt in de HTML;
- het logo van het laadscherm heeft een hoge prioriteit en een vrijgehouden plek;
- de lettertypen hebben reservelettertypen die op hun maten zijn afgestemd;
- de 3D-scène laadt alleen als de browser met de grafische kaart tekent en de bezoeker niet om minder beweging heeft gevraagd. Zo niet, dan krijgt die een lichte versie met dezelfde inhoud.
In PageSpeed Insights, dat in onze tests zonder grafische versnelling meet en daarom die lichte versie krijgt, scoort de homepage 100 voor prestaties op mobiel (gemeten op 5 oktober 2026). Hetzelfde passen we toe op elke website die we ontwerpen.
Veelgestelde vragen
Als mijn website goed scoort in PageSpeed Insights, haalt ze dan de Core Web Vitals? Niet per se. De score is een labtest; voor Google tellen de gegevens van je echte bezoeken van de laatste 28 dagen.
Waarom verandert de score bij elke test? Omdat de omstandigheden veranderen: het netwerk, de server of het testapparaat (Chrome for Developers). Test een paar keer en kijk naar de trend, niet naar één los getal.
Wat als mijn website weinig bezoeken heeft en er geen veldgegevens zijn? Ga uit van de labgegevens en los op wat ze aangeven. Zodra er genoeg bezoeken zijn, toont Search Console de echte gegevens.
Bronnen
- Core Web Vitals: wat ze zijn en hun drempels (web.dev).
- INP wordt op 12 maart 2024 een Core Web Vital (web.dev).
- Paginabeleving in de zoekresultaten van Google (Google Search Central).
- Rapport Core Web Vitals (Search Console Help).
- LCP, INP en CLS optimaliseren (web.dev).
- Milliseconds make millions: het onderzoek van Deloitte voor Google (web.dev).
- Hoe de prestatiescore van Lighthouse wordt berekend (Chrome for Developers).
