Core Web Vitals: drie metrics uitgelegd en wat je per metric kunt doen

Sinds maart 2024 vervangt INP (Interaction to Next Paint) de eerdere FID-metric. Sindsdien zijn de drie Core Web Vitals: LCP (laadsnelheid), INP (interactiesnelheid) en CLS (visuele stabiliteit). Voor wie zijn site in 2026 niet uit Google-rangschikkingen wil laten zakken, zijn deze drie metrics geen optioneel detail meer.

Dit artikel is technisch maar niet voor developers. Doelgroep: marketeers, webshop-eigenaren en MKB-eigenaars die willen begrijpen wat hun ontwikkelaar moet doen — en waarom. Voor de praktische uitvoering van de fixes lees ook website-snelheid verbeteren in WordPress, waar veel van onderstaande tactieken concreter staan.

Waarom Google deze metrics meet

Google's redenering: gebruikers verlaten sites die traag zijn, frustrerend reageren of waar dingen ineens verspringen. Een zoekmachine die zulke sites bovenaan zet, krijgt minder tevreden zoekers. Sinds 2020 zijn Core Web Vitals stapsgewijs een ranking-factor geworden — niet de zwaarste, maar wel meetbaar.

De metrics worden bovenmaten gemeten op mobiele apparaten met 4G-snelheid. Een site die op je glasvezel-laptop snel oogt kan op een 4G-mobiel ergens-in-een-trein onverbiddelijk traag voelen — Google gebruikt het laatste in zijn beoordeling.

Metric 1: LCP — Largest Contentful Paint

Wat het meet: hoe lang het duurt tot het grootste zichtbare element op je pagina geladen is. Vaak een banner-afbeelding, headline-tekst, of hero-video. Gemeten in seconden.

Doelwaarden:

• Goed: onder 2,5 seconden
• Verbetering nodig: 2,5 - 4,0 seconden
• Slecht: boven 4,0 seconden

Wat het meestal vertraagt:

• Grote, niet-geoptimaliseerde hero-afbeelding
• Render-blocking JavaScript voor de pagina kan beginnen
• Trage serverresponstijd (TTFB > 1 seconde)
• Hero-element wordt later via JavaScript ingeladen in plaats van direct in HTML

Concrete fix-tactieken:

• Hero-afbeelding optimaliseren (WebP, juiste afmeting, lazy-load uitschakelen voor specifiek dit element)
• 'preload' header toevoegen voor de hero-afbeelding
• Snellere hosting met TTFB onder 500ms
• Critical CSS inlinen, rest async laden
• Voor LCP-elementen die JavaScript-gegenereerd zijn: server-side renderen waar mogelijk

Metric 2: INP — Interaction to Next Paint

Wat het meet: hoe lang het duurt voordat je pagina reageert op een gebruikersinteractie (klik, tap, toetsdruk). Vervangt sinds 2024 de oude FID-metric. Gemeten in milliseconden.

Doelwaarden:

• Goed: onder 200ms
• Verbetering nodig: 200-500ms
• Slecht: boven 500ms

INP is voor veel WordPress-sites de moeilijkste metric. Een site kan visueel snel laden (goede LCP) maar daarna trage interacties hebben omdat zware JavaScript op de achtergrond draait.

Wat het meestal vertraagt:

• Te veel JavaScript dat synchroon draait
• Slechte third-party scripts (chat-widgets, analytics-tooling, sociale media-embeds)
• WordPress-plugins die JavaScript op elke pagina injecteren
• Zware DOM-structuur (te veel HTML-elementen)

Concrete fix-tactieken:

• Plugins identificeren die globaal JavaScript laden — heroverwegen of vervangen
• Third-party scripts asynchroon laden of laat-laden via Tag Manager
• JavaScript-code in kleinere chunks splitsen
• DOM-grootte reduceren (vooral op pagina's met veel dynamische content)

Metric 3: CLS — Cumulative Layout Shift

Wat het meet: hoe vaak en hoe sterk visuele elementen verspringen tijdens het laden van de pagina. Een score, geen tijdseenheid.

Doelwaarden:

• Goed: onder 0,1
• Verbetering nodig: 0,1 - 0,25
• Slecht: boven 0,25

CLS is voor gebruikers misschien de meest irritante metric. Het is de reden dat je op een knop wil klikken en die ineens een paar regels naar beneden verspringt — meestal omdat een afbeelding of advertentie laat geladen wordt en de rest van de content omhoog duwt.

Wat het meestal veroorzaakt:

• Afbeeldingen zonder vooraf gedefinieerde 'width' en 'height' attributen
• Advertenties of embed-content zonder gereserveerde ruimte
• Web fonts die later inladen en tekst doen verspringen (FOIT/FOUT)
• Dynamisch toegevoegde content boven bestaande content (cookie-banners die niet floaten)

Concrete fix-tactieken:

• Op alle afbeeldingen 'width' en 'height' attributen zetten (browser reserveert dan ruimte)
• 'font-display: swap' in plaats van 'block'
• Cookie-banners overlay-stijl maken in plaats van top-stack
• 'aspect-ratio' CSS voor videos en embeds
• Lazy-loaded content moet vaste hoogte hebben in placeholder-vorm

Hoe meet je je eigen Core Web Vitals?

Vier tools, complementair gebruiken:

1. PageSpeed Insights (pagespeed.web.dev): gratis Google-tool. Geeft je een momentopname van LCP/INP/CLS op één pagina. Geeft ook concrete suggesties voor verbetering.

2. Google Search Console — Core Web Vitals rapport: laat de Vitals zien voor je hele site, met groepering naar problematische URL-patronen. Belangrijk: deze data is gebaseerd op échte gebruiker-bezoeken, niet op lab-tests.

3. WebPageTest.org: gedetailleerde lab-tests waarmee je de exacte oorzaken van problemen kunt achterhalen. Steile leercurve maar nuttig voor diep-duiken.

4. Chrome DevTools — Performance tab: voor ontwikkelaars die JavaScript-bottlenecks willen vinden. Specifiek de 'Long tasks' sectie wijst INP-problemen aan.

In praktijk: begin met PageSpeed Insights om problemen te identificeren, gebruik Search Console om te zien welke pagina's structureel slecht scoren, gebruik WebPageTest om diepere oorzaken te vinden bij hardnekkige issues.

Wat verandert er bij Google als je Vitals slecht zijn?

Google communiceert dit zelf transparant: Core Web Vitals zijn een ranking-factor, maar geen overheersende. Een site met fenomenale content en slechte Vitals kan nog steeds bovenaan staan in nicheonderwerpen. Een site met middelmatige content en goede Vitals zal moeite hebben tegen sites met betere content.

De vuistregel: tussen twee gelijkwaardige zoekresultaten geeft Google voorrang aan degene met betere Vitals. In competitieve markten waar tien sites om dezelfde positie strijden is dit een doorslaggevende factor.

Daarnaast: gebruikers blijven langer op snelle, stabiele sites. Engagement-signalen (verblijftijd, bouncepercentage, conversies) worden indirect ook beïnvloed door Vitals. Goede Vitals leveren dus dubbel rendement.

Veelgemaakte misvattingen

Misvatting 1: "Mijn PageSpeed-score is 95, dus mijn Vitals zijn goed." Niet noodzakelijk. PageSpeed score is een aggregaat van labtests; Vitals worden gemeten in échte gebruikers. Een site kan in lab snel zijn maar voor mobiel-gebruikers traag — bijvoorbeeld omdat hun mobiel ouder is dan de test-device.

Misvatting 2: "Eén plugin lost mijn Vitals op." Geen enkele plugin lost LCP/INP/CLS volledig op. Plugins kunnen helpen (caching, image-optimization, JavaScript-defer), maar de fundamentele Vitals-problemen zitten vaak in thema-keuze, hostingkeuze, of architectuur — dingen die geen plugin kan oplossen.

Misvatting 3: "Vitals zijn voor grote sites; mijn kleine ZZP-site hoeft zich geen zorgen te maken." Onjuist. De kleinere de site, hoe meer elke individuele bezoeker telt. Een ZZP-site met slechte Vitals verliest absoluut gezien meer potentiële klanten dan een grote site die er evenveel verliest in procenten.

Onze aanpak bij Core Web Vitals

Bij Fast 4 You doen we een Core Web Vitals-scan onderdeel van elke nieuwe site-bouw en bij elke onderhoud-overstap. Voor bestaande sites die ergens haperen bieden we een gerichte Vitals-optimalisatie.

Vraag een Core Web Vitals-rapport aan — vrijblijvend, met een concrete actielijst per metric. Of lees over onze website-onderhouddienst waar maandelijkse Vitals-monitoring standaard is, en over hoe wij websites bouwen — daar starten Vitals al op groen vanaf dag één.