Core Web Vitals: complete gids voor 2026

technical-seo12 min leestijd

Core Web Vitals zijn Google's meetbare maatstaven voor gebruikerservaring. Ze meten drie dingen: hoe snel je pagina laadt (LCP), hoe snel je pagina reageert op interactie (INP), en hoe stabiel je layout is tijdens het laden (CLS). Samen zijn ze een bevestigde rankingfactor.

In 2025 haalde slechts 48% van mobiele pagina's een "goed" score op alle drie de metrics. Dat betekent dat meer dan de helft van het web technisch ondermaats presteert. In deze gids: wat elke metric meet, waar het meestal misgaat, en hoe je het fixt. Met concrete code, tools, en data uit Hiveminds-projecten.

Wat zijn Core Web Vitals?

Core Web Vitals zijn drie performance-metrics die Google gebruikt als rankingsignaal. Ze meten de daadwerkelijke gebruikerservaring, niet lab-data. Google verzamelt deze data via Chrome-gebruikers (het Chrome User Experience Report, CrUX) en gebruikt het 75e percentiel als drempel: minstens 75% van je bezoekers moet een "goed" score halen.

Metric	Wat het meet	Goed	Matig	Slecht
LCP	Laadsnelheid (grootste element)	< 2,5s	2,5 - 4,0s	> 4,0s
INP	Reactiesnelheid (alle interacties)	< 200ms	200 - 500ms	> 500ms
CLS	Visuele stabiliteit (layout shifts)	< 0,1	0,1 - 0,25	> 0,25

Belangrijk: CWV zijn een tiebreaker, geen dominante factor. Bij twee pagina's met vergelijkbare content-relevantie wint de pagina met betere CWV. Maar uitstekende CWV compenseren nooit voor slechte content.

De overgang van FID naar INP

In maart 2024 verving Google FID (First Input Delay) door INP (Interaction to Next Paint) als Core Web Vital. Het verschil is significant:

FID mat alleen de vertraging van de eerste interactie
INP mat alle interacties gedurende het hele paginabezoek en rapporteert het slechtste resultaat

INP is een strenger criterium. Sites die FID haalden, falen soms op INP. De reden: FID negeerde trage interacties na de eerste klik. INP niet.

LCP: Largest Contentful Paint

LCP meet hoe lang het duurt voordat het grootste zichtbare element in de viewport geladen is. Dat is meestal een hero-afbeelding, een grote kop, of een video-poster. De drempel is 2,5 seconden.

Slechts 62% van mobiele pagina's haalt een goede LCP-score. Het is de moeilijkste Core Web Vital om te halen.

Waar LCP meestal misgaat

LCP bestaat uit vier fasen. De meeste sites verliezen tijd in fase 2 en 3:

Fase	Wat het is	Typisch aandeel	Optimalisatie
1. TTFB	Server response time	30-50%	Server, CDN, caching
2. Resource load delay	Tijd tussen TTFB en start van image download	20-40%	Preload, fetchpriority
3. Resource load time	Daadwerkelijke download	10-20%	Compressie, CDN
4. Render delay	Rendering na download	5-15%	Geen render-blocking resources

De gemiddelde site met slechte LCP besteedt 2,27 seconden alleen al aan TTFB. Dat is bijna het hele 2,5-seconden budget.

LCP optimaliseren

1. Server response time verlagen (TTFB)

Target: TTFB < 800ms, ideaal < 200ms

Gebruik een CDN (Cloudflare, Fastly, AWS CloudFront)
Implementeer server-side caching (Redis, Varnish)
Optimaliseer database-queries
Gebruik HTTP/2 of HTTP/3

2. LCP-afbeelding preloaden

De #1 LCP-fix. Een preload hint vertelt de browser om de afbeelding direct te downloaden, zonder te wachten tot de HTML geparsed is.

<head>
  <link rel="preload" as="image" href="/hero.webp" fetchpriority="high">
</head>

Het fetchpriority="high" attribuut is cruciaal. Zonder het geeft de browser de afbeelding pas hoge prioriteit nadat hij de layout berekent. Met fetchpriority krijgt de afbeelding direct de hoogste prioriteit. Lazy-loaded LCP-afbeeldingen zijn 2x trager dan preloaded.

3. Afbeeldingen optimaliseren

<!-- Modern formaat, responsive, correcte grootte -->
<img
  src="/hero.webp"
  srcset="/hero-400.webp 400w, /hero-800.webp 800w, /hero-1200.webp 1200w"
  sizes="(max-width: 768px) 100vw, 1200px"
  width="1200"
  height="630"
  alt="Beschrijving"
  fetchpriority="high"
>

Gebruik WebP of AVIF (30-50% kleiner dan JPEG)
Serveer de juiste grootte per scherm (srcset)
Stel width en height in (voorkomt CLS)
Nooit lazy-loaden van de LCP-afbeelding

4. Render-blocking resources elimineren

CSS en synchrone scripts in de <head> blokkeren rendering. Minimaliseer critical CSS, defer non-critical CSS, en gebruik async of defer op scripts.

<!-- Kritieke CSS inline -->
<style>/* Alleen above-the-fold styles */</style>

<!-- Rest asynchroon laden -->
<link rel="stylesheet" href="/styles.css" media="print" onload="this.media='all'">

Hiveminds case: handler.gg

Voor handler.gg optimaliseerden we LCP van 4,2s naar 1,8s door drie maatregelen: hero-image preload met fetchpriority (grootste winst), migratie van client-side naar server-side rendering voor de landingspagina's, en Cloudflare CDN-caching. De combinatie haalde LCP ruim onder de 2,5s drempel.

INP: Interaction to Next Paint

INP meet de vertraging tussen een gebruikersinteractie (klik, tap, toetsaanslag) en de volgende visuele update. Het rapporteert de slechtste interactie gedurende het paginabezoek. De drempel is 200 milliseconden.

Hoe INP werkt

Een interactie bestaat uit drie fasen:

Input delay: wachttijd voordat de event handler start (vaak veroorzaakt door een draagende JavaScript-taak)
Processing time: uitvoertijd van de event handler zelf
Presentation delay: tijd om de DOM-wijziging te renderen en te painten

INP = input delay + processing time + presentation delay.

INP optimaliseren

1. Lange JavaScript-taken opsplitsen

De #1 oorzaak van slechte INP: JavaScript-taken die langer dan 50ms duren en de main thread blokkeren. De browser kan tijdens een lange taak niet reageren op gebruikersinput.

// Slecht: een lange taak blokkeert de main thread
function processLargeList(items) {
  items.forEach(item => heavyComputation(item));
}

// Beter: splits in chunks en yield naar de main thread
async function processLargeList(items) {
  const chunks = chunkArray(items, 50);
  for (const chunk of chunks) {
    chunk.forEach(item => heavyComputation(item));
    await new Promise(resolve => setTimeout(resolve, 0));
  }
}

2. Event handlers optimaliseren

Debounce frequente events (scroll, resize, input). Throttle klikhandlers die zware berekeningen triggeren.

// Debounce zoek-input
const debouncedSearch = debounce((query) => {
  performSearch(query);
}, 300);

input.addEventListener('input', (e) => debouncedSearch(e.target.value));

3. DOM-grootte beperken

Een DOM met meer dan 1.500 elementen vertraagt rendering na interacties merkbaar. Gebruik virtualization voor lange lijsten (react-window, TanStack Virtual). Vermijd onnodige wrapper-elementen.

4. React-specifieke optimalisaties

Gebruik React.memo() om onnodige re-renders te voorkomen
Gebruik useMemo en useCallback voor dure berekeningen
React 18: gebruik useTransition voor niet-urgente state updates
React 18: Suspense voor non-blocking hydration

// React 18: useTransition voor niet-urgente updates
const [isPending, startTransition] = useTransition();

function handleFilter(value) {
  // Urgent: update het input veld direct
  setInputValue(value);
  // Niet-urgent: filter de lijst op de achtergrond
  startTransition(() => {
    setFilteredList(filterItems(value));
  });
}

CLS: Cumulative Layout Shift

CLS meet hoeveel zichtbare elementen verschuiven nadat ze geladen zijn. Een layout shift is wanneer een element van positie verandert zonder dat de gebruiker dit verwacht. De drempel is 0,1.

Waar CLS meestal misgaat

1. Afbeeldingen zonder dimensies

De meest voorkomende CLS-oorzaak. De browser reserveert geen ruimte voor een afbeelding als width en height ontbreken. Zodra de afbeelding laadt, schuift alle content eronder.

<!-- Fout: geen dimensies -->
<img src="/photo.jpg" alt="Foto">

<!-- Goed: dimensies opgegeven -->
<img src="/photo.jpg" alt="Foto" width="800" height="450">

<!-- Goed: aspect-ratio via CSS -->
<img src="/photo.jpg" alt="Foto" style="aspect-ratio: 16/9; width: 100%;">

2. Web fonts die tekst herschikken

Wanneer een webfont laadt, vervangt het de fallback-font. Als de grootte verschilt, verschuift de layout. Dit heet FOUT (Flash of Unstyled Text).

/* Voorkom layout shift door font-display */
@font-face {
  font-family: 'BebasNeue';
  src: url('/fonts/bebas-neue.woff2') format('woff2');
  font-display: swap; /* of optional voor minimale shift */
}

font-display: optional geeft de kleinste CLS. Als het font niet binnen 100ms laadt, gebruikt de browser de fallback permanent voor die paginaweergave. De trade-off: soms zie je je custom font niet bij de eerste pageload.

3. Advertenties en embeds zonder gereserveerde ruimte

Ads die later inladen, duwen content naar beneden. Reserveer altijd ruimte met een min-height:

.ad-container {
  min-height: 250px; /* Reserveer ruimte voor ad */
}

4. Dynamisch ingevoegde content

Banners, cookie-meldingen, en notificaties die boven bestaande content worden geplaatst. Gebruik liever overlays (position: fixed) of voeg content onder de viewport toe.

CLS meten en debuggen

// CLS-bronnen identificeren via Performance Observer
new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    if (!entry.hadRecentInput) {
      console.log('Layout shift:', entry.value, entry.sources);
    }
  }
}).observe({ type: 'layout-shift', buffered: true });

Chrome DevTools > Performance tab > kijk naar "Layout Shift" entries. Ze tonen precies welk element verschoof en waarom.

TTFB: Time to First Byte

TTFB is geen officieel Core Web Vital, maar het is de basis waarop LCP gebouwd is. Een slechte TTFB maakt een goede LCP onmogelijk.

TTFB meet de tijd tussen het HTTP-request en de eerste byte van de response. Het omvat DNS-lookup, TCP-verbinding, TLS-handshake, en server-processing.

TTFB	Beoordeling
< 200ms	Goed
200 - 600ms	Acceptabel
> 600ms	Problematisch

TTFB verlagen

Optimalisatie	Typische impact	Complexiteit
CDN activeren	-50 tot -200ms	Laag
Server-side caching (Redis)	-100 tot -500ms	Middel
Database-query optimalisatie	-50 tot -300ms	Hoog
HTTP/2 of HTTP/3	-20 tot -100ms	Laag
Stale-while-revalidate caching	-100 tot -400ms	Middel

Tools en monitoring

Lab tools (gesimuleerde data)

Tool	Wat het meet	Wanneer gebruiken
PageSpeed Insights	CWV + Lighthouse audit + CrUX data	Eerste diagnose
Lighthouse (Chrome DevTools)	Performance audit met details	Debugging specifieke issues
WebPageTest	Waterfalls, filmstrip, resource timing	Diepgaande analyse

Field data (echte gebruikersdata)

Tool	Wat het meet	Wanneer gebruiken
CrUX Dashboard	CWV per origin, 28-dagen rolling	Trendanalyse
Search Console CWV rapport	Per URL groep, goed/matig/slecht	Impact op indexering
Google Analytics / web-vitals.js	Per-paginaniveau CWV	Granulaire monitoring

web-vitals.js implementeren

import { onLCP, onINP, onCLS } from 'web-vitals';

onLCP(metric => sendToAnalytics('LCP', metric));
onINP(metric => sendToAnalytics('INP', metric));
onCLS(metric => sendToAnalytics('CLS', metric));

function sendToAnalytics(name, metric) {
  // Stuur naar je analytics platform
  console.log(`${name}: ${metric.value}`);
}

Structureel CWV monitoren

Core Web Vitals optimaliseren is geen eenmalige actie. Performance degradeert over tijd door nieuwe features, third-party scripts, en content-wijzigingen. Bouw monitoring in je workflow:

Wekelijks:

Check CWV-rapport in Search Console op nieuwe "slechte" URL-groepen
Review PageSpeed Insights score van je top-5 landing pages

Bij elke deploy:

Run Lighthouse CI als onderdeel van je build pipeline
Stel budgetten in: LCP < 2,5s, INP < 200ms, CLS < 0,1

Maandelijks:

Analyseer CrUX trends (verslechtert of verbetert het?)
Audit third-party scripts (elke nieuwe script is een potentieel CWV-risico)

Lighthouse CI voorbeeld

# lighthouserc.json
{
  "ci": {
    "assert": {
      "assertions": {
        "categories:performance": ["error", {"minScore": 0.9}],
        "largest-contentful-paint": ["error", {"maxNumericValue": 2500}],
        "interactive": ["error", {"maxNumericValue": 3500}],
        "cumulative-layout-shift": ["error", {"maxNumericValue": 0.1}]
      }
    }
  }
}

Veelgestelde vragen

Zijn Core Web Vitals een sterke rankingfactor? Ze zijn een bevestigde maar lichte rankingfactor. Bij gelijke content-relevantie wint de pagina met betere CWV. Maar uitstekende performance compenseert niet voor zwakke content. Zie het als een hygienefactor: je verliest geen race door goede CWV, maar je kunt er een mee winnen bij een gelijkspel.

Mijn Lighthouse-score is 100 maar CrUX toont slecht. Hoe kan dat? Lighthouse meet lab-data (gesimuleerde omstandigheden). CrUX meet field-data (echte gebruikers op echte apparaten). Een gebruiker op een 3G-verbinding in een trein heeft een heel andere ervaring dan je Lighthouse-test op glasvezel. Field data is wat Google gebruikt voor rankings.

Heeft INP impact op sites zonder JavaScript? Minimaal. INP meet de reactiesnelheid op interacties. Statische HTML-sites zonder JavaScript-interacties scoren bijna altijd goed op INP. Het is primair een probleem voor JavaScript-heavy applicaties.

Hoe lang duurt het voordat CWV-verbeteringen rankingeffect hebben? Google gebruikt 28-dagen rolling CrUX-data. Na een verbetering duurt het dus minimaal 28 dagen voordat de nieuwe data in CrUX reflecteert, plus de tijd die Google nodig heeft om dit in rankings te verwerken. Reken op 4-8 weken.

Moet ik CWV op elke pagina optimaliseren? Focus op pagina's die traffic genereren. De homepage, top landing pages, en categoriepagina's. Google evalueert CWV per URL-groep in Search Console. Een slechte CWV op je privacybeleid-pagina beïnvloedt je productpagina's niet.

Beïnvloeden CWV ook AI-zichtbaarheid? Niet direct. AI-systemen (ChatGPT, Perplexity) meten geen CWV. Maar slechte performance correleert met slechte crawlbaarheid (trage servers geven minder crawlbudget), en de rendering-strategie die CWV beïnvloedt (SSR vs CSR) bepaalt of AI-bots je content kunnen lezen. Meer hierover: JavaScript SEO.

Volgende stap

Core Web Vitals zijn het meetbare fundament van je site-performance. Gecombineerd met goede crawlbaarheid, correcte structured data, en een doordachte rendering-strategie, bouw je een technisch sterke basis voor zowel Google als AI-zoekmachines.

Hiveminds Lens analyseert je technische SEO-gezondheid naast AI-zichtbaarheid. Een complete diagnose die laat zien waar je staat en wat prioriteit heeft.

→ Bekijk Hiveminds Lens