Wat zijn de Core Web Vitals en welke drempelwaarden gelden
Core Web Vitals zijn drie metrics waarmee Google de gebruikerservaring van een pagina meet: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) en Cumulative Layout Shift (CLS). Voor een goede score moet LCP binnen 2,5 seconden vallen, INP onder 200 milliseconden blijven en CLS onder 0,1 blijven.
Google beoordeelt deze drempelwaarden niet op het gemiddelde bezoek, maar op het 75e percentiel van echte bezoekersdata uit de Chrome-gebruikersstatistieken: minstens driekwart van uw bezoekers moet de pagina als "goed" ervaren voordat de pagina als geheel door de toets komt. Eén snelle test op uw eigen snelle kantoorverbinding zegt dus weinig; de score wordt bepaald door bezoekers met uiteenlopende apparaten en verbindingen.
Wat meet LCP en hoe verbetert u de laadtijd
LCP meet hoe snel het grootste zichtbare element in het eerste scherm, meestal een hero-afbeelding of een grote kop, volledig is geladen. Trage LCP-tijden ontstaan meestal door een combinatie van een langzame serverreactie, te grote onbewerkte afbeeldingen en render-blokkerende CSS of JavaScript die het laden van de rest van de pagina vertragen.
De grootste winst zit doorgaans in afbeeldingsoptimalisatie: comprimeer en converteer afbeeldingen naar een modern formaat zoals WebP, serveer ze in de juiste afmeting in plaats van een groot origineel te verkleinen met CSS, en preload de belangrijkste hero-afbeelding zodat de browser die niet pas laat in het laadproces ontdekt. Kies daarnaast hosting met een snelle serverreactietijd en overweeg een CDN als bezoekers geografisch verspreid zijn.
Wat meet INP en hoe maakt u de site responsiever
INP meet hoe snel een pagina reageert op een klik, tik of toetsaanslag, gedurende het volledige bezoek in plaats van alleen bij de eerste interactie. Deze metric verving in maart 2024 de oudere First Input Delay (FID) juist omdat FID alleen die eerste interactie mat, terwijl trage reacties later in een bezoek voor gebruikers minstens zo storend zijn.
Een hoge INP komt meestal door JavaScript die de hoofdthread langdurig blokkeert, waardoor de browser niet kan reageren op invoer van de gebruiker. Verminder de hoeveelheid en zwaarte van derde partijscripts zoals advertenties, chatwidgets en trackingscripts, splits lange JavaScript-taken op in kleinere stukken, en stel niet-kritieke scripts uit tot na het laden van de zichtbare content.
Wat meet CLS en hoe voorkomt u onverwachte layoutverschuivingen
CLS meet hoeveel zichtbare elementen onverwacht verschuiven tijdens het laden van de pagina, bijvoorbeeld wanneer een advertentie plotseling ruimte inneemt en de tekst eronder wegduwt. Voor de bezoeker voelt dit vervelend aan, zeker als het per ongeluk leidt tot een verkeerde klik.
De meest voorkomende oorzaken zijn afbeeldingen en advertenties zonder vooraf gereserveerde afmetingen, webfonts die pas laat inladen en de tekst laten "springen", en dynamisch ingeladen content die boven bestaande content wordt geplaatst. Geef elke afbeelding en video expliciete breedte- en hoogte-attributen of een aspect-ratio, reserveer vaste ruimte voor advertentieblokken nog voordat de advertentie zelf laadt, en wees terughoudend met content die pas na de eerste weergave bovenin de pagina verschijnt.
Waar controleert u uw eigen Core Web Vitals-score
Het Core Web Vitals-rapport in Google Search Console toont veldgegevens van echte bezoekers, gegroepeerd per type pagina, en ververst op basis van een voortschrijdend gemiddelde van de afgelopen 28 dagen. Dit is de data die daadwerkelijk meetelt voor Google, maar heeft als nadeel dat nieuwe pagina's of recente wijzigingen pas na enkele weken zichtbaar worden in het rapport.
PageSpeed Insights combineert deze veldgegevens met directe labdata en is daarmee geschikt om zowel de huidige praktijkscore te zien als een concrete pagina meteen te testen na een wijziging. Lighthouse in de Chrome-ontwikkelaarstools geeft alleen labdata in een gecontroleerde omgeving, wat vooral nuttig is om een wijziging te debuggen voordat er genoeg echte bezoekersdata is verzameld om die in Search Console te bevestigen.
Wat is het verschil tussen labdata en veldgegevens
Labdata ontstaat in een gecontroleerde testomgeving, bijvoorbeeld door Lighthouse in de Chrome-ontwikkelaarstools op één vaste verbinding en één vast toestel. Dit is reproduceerbaar en handig om een specifieke wijziging te testen, maar zegt niets over hoe de pagina in de praktijk presteert bij een breed publiek.
Veldgegevens, ook wel Real User Monitoring genoemd, komen van daadwerkelijke bezoekers met hun eigen toestel, verbinding en locatie, verzameld via het Chrome User Experience Report (CrUX). Dit is de data die Google gebruikt voor de Core Web Vitals-beoordeling in Search Console. Een pagina kan in het lab uitstekend scoren en tegelijk in het veld onder de norm blijven, simpelweg omdat een aanzienlijk deel van de bezoekers een trager toestel of een minder stabiele verbinding gebruikt dan de testomgeving.
Praktische maatregelen die op de meeste sites winst opleveren
Een aantal ingrepen levert op vrijwel elke site meetbare verbetering op, ongeacht het specifieke platform:
- afbeeldingen comprimeren en naar WebP converteren, met de juiste afmeting per gebruikte weergave
- lazy loading toepassen op afbeeldingen onder de vouw, maar nooit op de hero-afbeelding die de LCP bepaalt
- browsercaching en compressie (zoals gzip of brotli) instellen op serverniveau
- het aantal actieve plug-ins, widgets en trackingscripts kritisch beperken tot wat daadwerkelijk waarde toevoegt
- snelle, goed geconfigureerde hosting kiezen in plaats van achteraf te blijven optimaliseren op trage infrastructuur
- onnodige redirects verwijderen, want elke extra omleiding kost tijd voordat de daadwerkelijke pagina begint te laden
Hoe wegen mobiel en desktop mee in de score
Google beoordeelt Core Web Vitals apart voor mobiel en desktop, en aangezien de zoekmachine mobile-first indexeert, weegt de mobiele score in de praktijk het zwaarst. Een pagina die op een snelle desktopverbinding uitstekend presteert, kan op een gemiddeld mobiel toestel met een tragere verbinding alsnog ruim boven de drempelwaarden uitkomen.
Test daarom altijd expliciet de mobiele score, niet alleen de desktopvariant, en houd rekening met een breder scala aan toestellen dan alleen de nieuwste modellen. PageSpeed Insights toont beide scores los van elkaar, wat meteen zichtbaar maakt of een probleem specifiek mobiel speelt, bijvoorbeeld door zwaardere afbeeldingen dan nodig of door scripts die op een minder krachtige processor meer tijd kosten om uit te voeren.
Veelgemaakte fouten bij het verbeteren van Core Web Vitals
Een veelgemaakte fout is uitsluitend optimaliseren voor een goede labscore in de ontwikkelaarstools, terwijl de werkelijke veldgegevens van bezoekers met tragere verbindingen of oudere toestellen een ander beeld geven. Vertrouw bij de uiteindelijke beoordeling altijd op de veldgegevens uit Search Console.
Een tweede fout is lazy loading toepassen op de hero-afbeelding zelf, in de veronderstelling dat dit de pagina sneller maakt: voor het element dat de LCP bepaalt werkt dit averechts, omdat de browser dan juist wacht met laden tot het element in beeld zou moeten komen. Reserveer lazy loading voor content verderop op de pagina, en preload juist de afbeelding die het eerste scherm bepaalt.
Een derde, minder voor de hand liggende fout is het toevoegen van steeds meer losse plug-ins of scripts die stuk voor stuk beloven de snelheid te verbeteren, zoals een caching-plug-in naast een afbeeldingsoptimalisatie-plug-in naast een lazy-loading-script. Elk van die toevoegingen brengt zelf weer JavaScript mee, en de stapeling kan per saldo INP juist verslechteren. Een opgeschoonde basis met minder, doelgerichte aanpassingen werkt in de praktijk vaak beter dan steeds meer losse oplossingen boven op elkaar.
