Wat zijn Core Web Vitals?
Core Web Vitals zijn een set van drie concrete metingen waarmee Google de gebruikerservaring van een pagina probeert te vangen. Niet abstract ("voelt snel"), maar in getallen: hoe snel de belangrijkste inhoud verschijnt, hoe stabiel de layout blijft tijdens het laden, en hoe snel de pagina reageert als je iets aanklikt.
Google gebruikt deze scores sinds 2021 als onderdeel van de "page experience"-signalen. Belangrijk om te begrijpen: het is een van de vele ranking-factoren, geen doorslaggevende. Een pagina met perfecte Core Web Vitals maar zwakke content rankt niet vanzelf. Andersom kost een dramatisch trage pagina je wel posities, en veel bezoekers.
De drie metrics zijn LCP, CLS en INP. INP verving in maart 2024 de oudere metric FID (First Input Delay). Als je nog ergens FID tegenkomt: dat is verouderd. INP meet hetzelfde idee (reactiesnelheid) maar dan strenger en over de hele bezoek in plaats van alleen de eerste interactie.
LCP: Largest Contentful Paint
LCP meet hoe lang het duurt voordat het grootste zichtbare element op je pagina is geladen. Meestal is dat een hero-afbeelding, een grote kop of een blok tekst boven de vouw. In gewone taal: hoe snel ziet de bezoeker waar de pagina eigenlijk over gaat.
De streefwaarde is onder 2,5 seconde. Tussen 2,5 en 4 seconde is "needs improvement", boven 4 seconde is slecht. Op mobiel is dit vaak het lastigst, omdat verbindingen trager zijn en telefoons minder rekenkracht hebben.
De grootste boosdoeners voor een trage LCP zijn zware, ongecomprimeerde afbeeldingen, een langzame server-reactietijd, en render-blokkerende CSS of JavaScript. De volledige aanpak staat in onze gids LCP verlagen: 8 concrete verbeteringen.
- Comprimeer je hero-afbeelding en serveer hem als WebP: dat scheelt vaak 40 tot 70 procent bestandsgrootte.
- Snelle server: een trage hosting-reactie (TTFB) tikt direct door in je LCP. LiteSpeed-servers reageren hier merkbaar sneller.
- Preload het LCP-element zodat de browser het als eerste ophaalt, niet als laatste.
CLS: Cumulative Layout Shift
CLS meet hoeveel de layout van je pagina onverwacht verspringt tijdens het laden. Je kent het gevoel: je wilt op een knop klikken, er laadt nog een advertentie of afbeelding in, en de knop schuift weg. Dat verspringen is precies wat CLS meet.
De streefwaarde is onder 0,1. Boven 0,25 is slecht. CLS is geen tijd maar een verhoudingsgetal: hoeveel schermoppervlak verschuift, maal hoe ver het verschuift.
De meest voorkomende oorzaken zijn afbeeldingen en video's zonder vaste breedte en hoogte, advertenties of embeds die ruimte innemen nadat de tekst al staat, en lettertypes die laat inladen waardoor tekst herschikt. De concrete oplossingen staan in CLS oplossen: layout shifts stoppen.
INP: Interaction to Next Paint
INP meet hoe snel je pagina zichtbaar reageert nadat een bezoeker iets doet: een klik, een tik of een toetsaanslag. Het gaat om de vertraging tussen de actie en het moment dat je op het scherm ziet dat er iets gebeurt. Een trage INP voelt als een site die "hangt".
De streefwaarde is onder 200 milliseconden. Tussen 200 en 500 ms is matig, daarboven slecht. INP is bijna altijd een JavaScript-probleem: te veel of te zwaar script dat de hoofdthread van de browser bezet houdt terwijl de gebruiker wacht.
Voor de meeste WordPress-sites komt een slechte INP door een stapel plugins die elk hun eigen JavaScript laden. Meer over de achtergrond in INP (Interaction to Next Paint): de nieuwe metric.
De drempelwaarden op een rij
Google beoordeelt je op het 75e percentiel van echte bezoekers. Dat betekent: driekwart van je bezoekers moet binnen de "goede" grens vallen, niet het gemiddelde. Eén trage uitschieter telt dus zwaarder dan je denkt.
- LCP · goed: onder 2,5 s · matig: 2,5 tot 4 s · slecht: boven 4 s
- CLS · goed: onder 0,1 · matig: 0,1 tot 0,25 · slecht: boven 0,25
- INP · goed: onder 200 ms · matig: 200 tot 500 ms · slecht: boven 500 ms
Core Web Vitals zijn geen doel op zich. Ze zijn een spiegel: ze vertellen je of je bezoekers een vlotte site ervaren of een frustrerende. Fix ze voor de mensen, niet voor de score, en de score volgt vanzelf.
Waar meet je Core Web Vitals?
Er zijn twee soorten data, en het verschil is belangrijk. Lab-data is een test onder gecontroleerde omstandigheden (altijd hetzelfde apparaat en dezelfde verbinding). Veld-data (CrUX, Chrome User Experience Report) is wat echte bezoekers de afgelopen 28 dagen ervoeren. Google rankt op veld-data, niet op lab-data.
- PageSpeed Insights toont beide: lab- en veldscores. Zie PageSpeed Insights lezen en gebruiken.
- Google Search Console heeft een Core Web Vitals-rapport dat je hele site groepeert in goed, matig en slecht.
- Chrome DevTools (Lighthouse) voor een snelle lab-test tijdens het bouwen.
- Onze gratis site-check meet je Core Web Vitals mee in een leesbaar rapport.
Praktijkvoorbeeld: een WordPress-site sneller maken
Neem een typische MKB-site: WordPress met Elementor, een thema-slider op de homepage, en zeven plugins. Bij de start: LCP 4,8 seconde op mobiel, CLS 0,32, INP 340 ms. Alle drie in het rood.
Stap 1, afbeeldingen: de hero-slider werd vervangen door één statische WebP-afbeelding met vaste afmetingen. LCP zakte naar 3,1 seconde, CLS naar 0,08.
Stap 2, caching: de LiteSpeed Cache plugin ingesteld met CSS- en JS-minificatie en lazy-loading van onderliggende afbeeldingen. LCP naar 2,3 seconde.
Stap 3, JavaScript: twee overbodige plugins verwijderd en een deel van het script uitgesteld tot na interactie. INP zakte naar 180 ms.
Resultaat: alle drie in het groen, en, belangrijker, de bounce rate op mobiel daalde met ongeveer een vijfde. Dat is het echte rendement: minder mensen die afhaken voordat je site geladen is. Reken op een halve tot een hele dag werk voor een gemiddelde site.
Veelgemaakte fouten
Bij het optimaliseren van Core Web Vitals gaan MKB-sites vaak op dezelfde manieren de mist in. Deze vier zien we het vaakst.
- Alleen op de lab-score jagen: een groene Lighthouse-score op je snelle laptop zegt weinig over je mobiele bezoeker op 4G. Kijk naar de veld-data.
- Te veel caching-plugins stapelen: twee cache-plugins tegelijk werken elkaar tegen en breken je site. Kies er een.
- Alles lazy-loaden, ook het LCP-element: je hero-afbeelding lazy-loaden maakt je LCP juist trager. Sluit het bovenste beeld uit.
- Snelheid negeren omdat de content goed is: goede content op een trage WordPress-site verliest alsnog bezoekers. Beide moeten kloppen.