Core Web Vitals zijn drie metingen waarmee Google beschrijft hoe een pagina aanvoelt: hoe snel de belangrijkste inhoud verschijnt, hoe vlot de pagina reageert op een tik of klik en of de inhoud stil blijft staan tijdens het laden. Ze tellen mee in hoe Google de ervaring op een pagina beoordeelt. Ze zijn wel een van vele signalen: een snelle pagina die de vraag niet beantwoordt, wint het niet van een iets tragere die dat wel doet.
Voor een mkb-bedrijf is de belangrijkste reden om erop te letten eenvoudiger. Een klant die op zijn telefoon je boekingspagina opent en tien seconden naar een leeg scherm kijkt, boekt ergens anders.
De drie metingen en hun grenzen
| Meting | Wat het meet | Goed | Slecht |
|---|---|---|---|
| LCP (Largest Contentful Paint) | Hoe snel het grootste zichtbare element verschijnt, vaak een foto of kop | Maximaal 2,5 seconde | Meer dan 4 seconden |
| INP (Interaction to Next Paint) | Hoe snel de pagina zichtbaar reageert op tikken, klikken en toetsen | Maximaal 200 milliseconden | Meer dan 500 milliseconden |
| CLS (Cumulative Layout Shift) | Hoeveel inhoud onverwacht verschuift tijdens het bekijken | Maximaal 0,1 | Meer dan 0,25 |
Daartussen zit de beoordeling “verbetering nodig”. INP verving in maart 2024 de oudere meting FID (First Input Delay). FID keek alleen naar de vertraging bij de eerste interactie; INP kijkt naar de reacties gedurende het hele bezoek en is daardoor strenger.
Het 75e percentiel
Google beoordeelt niet het gemiddelde, maar het 75e percentiel van echte paginaweergaven, apart voor mobiel en desktop. Een pagina is “goed” als minstens driekwart van de bezoeken binnen de grens blijft. Een snelle laptop op kantoorwifi zegt dus weinig: de trage telefoon in de tram telt net zo goed mee.
Velddata en labdata
Er zijn twee soorten metingen en ze geven vaak verschillende uitkomsten. Dat is geen fout; ze meten iets anders.
Velddata: echte bezoekers
Velddata komt uit het Chrome-gebruikersrapport (CrUX): metingen van Chrome-gebruikers die het delen van gebruiksstatistieken hebben aangezet, over de afgelopen 28 dagen. Dit is de data waarop Google zich baseert. Je ziet hem op twee plekken:
- Search Console: het rapport Core Web Vitals groepeert vergelijkbare pagina’s en laat zien welke groepen goed, matig of slecht scoren.
- PageSpeed Insights: het bovenste deel van het rapport toont velddata voor de pagina of het hele domein, als er genoeg bezoekers zijn.
Heeft je site weinig bezoek, dan is er soms geen velddata beschikbaar. Je kunt de metingen dan op je eigen site verzamelen met een klein meetscript, of je baseert je tijdelijk op labdata.
Labdata: een gesimuleerde test
Lighthouse, ook onderdeel van PageSpeed Insights en de ontwikkelaarstools in Chrome, laadt je pagina één keer onder vaste omstandigheden: een gesimuleerde middenklasse telefoon met een tragere verbinding. Handig om oorzaken te vinden en om voor en na een wijziging te vergelijken.
- De score van 0 tot 100 is een samenvatting van labmetingen, geen Core Web Vital. Een 90 garandeert geen goede velddata en een 70 betekent niet dat echte bezoekers een slechte ervaring hebben.
- INP kan Lighthouse niet meten, omdat er bij een automatische laadtest niemand klikt. Lighthouse toont in plaats daarvan Total Blocking Time als aanwijzing.
Veelvoorkomende oorzaken op mkb-sites
- Trage LCP: een grote headerfoto die niet verkleind is, een slider met vijf foto’s bovenaan, of een server die lang nadenkt voor de eerste byte komt. Bij een restaurant is het vaak de sfeerfoto op volle cameragrootte.
- Slechte INP: veel scripts die tegelijk draaien: chatwidget, advertentiepixels, een zware boekingsmodule. Op een webwinkel voel je het bij filters die pas na een seconde reageren.
- Hoge CLS: afbeeldingen zonder vaste afmetingen, een cookiemelding die de pagina naar beneden duwt, of een lettertype dat bij het laden van grootte verandert. De klant tikt op “Bel ons” en raakt net de knop die eronder schoof.
Hoe je de laadtijd zelf omlaag brengt, met afbeeldingen, lettertypes en scripts van derden, lees je in ons artikel over een snelle website.
Wat je als mkb-bedrijf ermee doet
- Kijk eerst in Search Console: staan er pagina’s op slecht of verbetering nodig, en zijn het mobiele of desktoppagina’s?
- Begin bij de pagina’s die geld opleveren: je homepage, je dienstpagina’s en de pagina waar klanten boeken of bestellen.
- Gebruik Lighthouse om de oorzaak te vinden: het rapport noemt per meting welke elementen het meest bijdragen.
- Ruim scripts op: elke widget of pixel die niemand meer gebruikt, kost reactiesnelheid.
- Wacht op de velddata: omdat CrUX over 28 dagen rekent, zie je een verbetering pas na een paar weken volledig terug.
Houd daarnaast je eigen cijfers bij: aanvragen, boekingen en bestellingen. Een betere meting is pas echt iets waard als bezoekers minder vaak afhaken.
De websites die we naast onze software bouwen worden opgeleverd met geoptimaliseerde afbeeldingen, vaste afmetingen voor beeld en zo min mogelijk scripts van derden, zodat ze binnen de grenzen blijven op een gewone telefoon.
Veelgestelde vragen
Wat is een goede LCP?
Maximaal 2,5 seconde, gemeten bij het 75e percentiel van echte bezoeken. Boven de 4 seconden noemt Google het slecht.
Waarom verschilt PageSpeed Insights van Search Console?
Search Console toont velddata van echte Chrome-gebruikers over 28 dagen. De Lighthouse-score in PageSpeed Insights is één gesimuleerde test. Beide zijn bruikbaar, maar voor Google telt de velddata.
Bestaat FID nog?
Nee, sinds maart 2024 is INP de Core Web Vital voor reactiesnelheid. FID wordt niet meer gebruikt.
Kom ik met goede Core Web Vitals bovenaan in Google?
Niet vanzelf. Ze tellen mee, maar relevantie en de kwaliteit van de inhoud wegen zwaarder.