Wat Core Web Vitals echt aan omzet kosten

Core Web Vitals worden vaak behandeld als een puur SEO-onderwerp. Die insteek doet de meetwaarden tekort: als rankingsignaal zijn ze ondergeschikt — Google heeft zelf bevestigd dat een relevante pagina met de beste inhoud een snellere pagina met matige content nog steeds overtreft.

De echte reden om om prestaties te geven is conversie. Een bezoeker die wegklikt voordat de pagina zichtbaar is, converteert met exact nul procent — en geen enkele zoekpositie kan dat compenseren.

Hier leest u wat de drie kernmetrieken meten, wat slechte scores veroorzaakt en hoe u ze prioriteert.

De drie meetwaarden

Largest Contentful Paint (LCP)

Het moment waarop het grootste zichtbare element klaar is met renderen. Meestal de hero-afbeelding, de hoofdtitel (H1) of een groot tekstblok.

• Goed: onder 2,5 seconden
• Matig: 2,5–4,0 seconden
• Slecht: boven 4,0 seconden

LCP is de meest directe indicator voor 'wanneer werd deze pagina bruikbaar voor de bezoeker'. Dit is de eerste metriek die u moet optimaliseren.

Cumulative Layout Shift (CLS)

Hoeveel elementen verschuiven tijdens het laden. Iedereen heeft dit meegemaakt: u wilt op een knop tikken, er laadt een advertentie of banner boven, de pagina verspringt en u klikt op het verkeerde element.

• Goed: onder 0,1
• Slecht: boven 0,25

CLS is meestal snel en goedkoop op te lossen, omdat de oorzaken technisch eenduidig zijn.

Interaction to Next Paint (INP)

Hoe snel de pagina visueel reageert op gebruikersinteracties (klikken, tikken, toetsenbordinvoer). INP verving in maart 2024 de oude First Input Delay (FID) en is aanzienlijk strenger: het meet alle interacties gedurende het hele bezoek, niet alleen de eerste.

• Goed: onder 200 ms
• Slecht: boven 500 ms

Een slechte INP is vrijwel altijd een JavaScript-probleem: de hoofddraad (main thread) is geblokkeerd en kan de interface niet direct opnieuw tekenen.

Laboratoriumdata versus Velddata

Lighthouse-rapporten in uw browser meten 'Lab data' onder gesimuleerde omstandigheden. Google's rankings en het Chrome User Experience Report (CrUX) baseren zich echter uitsluitend op 'Velddata' (Real User Monitoring): daadwerkelijke metingen van echte gebruikers op echte netwerken over een periode van 28 dagen.

Als uw mobiele bezoekers op een trage 4G-verbinding zitten met een budgettelefoon, telt hún ervaring — niet uw snelle kantoor-MacBook.

Wat u in welke volgorde oplost

Stap 1: Fix LCP

1. Optimaliseer de hero-afbeelding: Gebruik WebP of AVIF, responsive srcset-afbeeldingen en geef de hero-afbeelding prioriteit met fetchpriority="high".
2. Verwijder render-blocking CSS en scripts: Laad niet-kritieke scripts asynchroon (defer of async).
3. Zorg voor een snelle serverreactietijd (TTFB): Gebruik een CDN (zoals Cloudflare of Fastly) en effectieve edge-caching.

Stap 2: Fix CLS

1. Geef alle afbeeldingen en video's expliciete afmetingen: Voeg altijd width en height attributen of CSS aspect-ratio toe zodat de browser vooraf ruimte reserveert.
2. Reserveer ruimte voor dynamische content: Advertentievlakken, cookiemeldingen en widgets moeten een vaste containerhoogte hebben.
3. Voorkom late lettertype-verschuivingen: Gebruik font-display: swap met fallback-lettertypen die dezelfde afmetingen hebben.

Stap 3: Fix INP

1. Verminder zware JavaScript-pakketten: Verwijder ongebruikte trackingpixels en bibliotheken via Google Tag Manager.
2. Splits lange taken op: Breek lange scripts op met scheduler.yield() of setTimeout zodat de browser tussentijds kan reageren.
3. Vermijd zware DOM-wijzigingen: Minimaliseer complexe re-renders bij interactieve elementen.

Snelle websites ranken beter, maar bovenal verkopen ze aanzienlijk meer.

Tool openen SEO & Snelheidsaudit Actuele Core Web Vitals via Google's API, plus live on-page controles op uw werkelijke HTML. →