De Core Web Vitals van 2026: wat er echt is veranderd en waarom het uitmaakt

Core Web Vitals zijn de drie snelheidsmetingen die Google in zijn rankingsystemen meeweegt: LCP (laden, maximaal 2,5 seconden), INP (reactie op interactie, maximaal 200 ms) en CLS (verspringen van de layout, maximaal 0,1). In 2026 haalt minder dan de helft van de mobiele sites alle drie. De grootste winst zit bij LCP, de meeste verwarring bij INP.

Wat zijn de drempels in 2026?

De drempels zijn sinds de invoering van INP niet meer verschoven. Google meet ze op het 75e percentiel van echte paginaweergaven, apart voor mobiel en desktop (web.dev). Je hoeft dus niet elke bezoeker onder de grens te krijgen, wel driekwart van je bezoekers.

Metric	Goed	Verbetering nodig	Slecht	Bron
LCP (Largest Contentful Paint)	2,5 s of minder	2,5 tot 4,0 s	meer dan 4,0 s	web.dev
INP (Interaction to Next Paint)	200 ms of minder	200 tot 500 ms	meer dan 500 ms	web.dev
CLS (Cumulative Layout Shift)	0,1 of minder	0,1 tot 0,25	meer dan 0,25	web.dev

Core Web Vitals tellen sinds de page experience update van juni 2021 mee in de ranking (Google Search Central). Google zegt er zelf bij dat relevante inhoud altijd voorgaat en dat een goede score geen toppositie garandeert (Google Search Central). Snelheid is het verschil tussen twee even goede pagina’s, niet de vervanging van goede content.

Waarom is INP anders dan FID?

INP (Interaction to Next Paint) verving First Input Delay op 12 maart 2024 als Core Web Vital (web.dev). FID mat alleen de allereerste klik. INP kijkt naar alle klikken, taps en toetsaanslagen tijdens een bezoek en rapporteert de traagste, waarbij per 50 interacties één uitschieter wordt genegeerd (web.dev).

Dat verklaart waarom sites die onder FID prima scoorden onder INP door de mand vallen. Een menu dat direct opent maar een filter dat de hele pagina blokkeert, telt nu wel mee. Op mobiel haalt 77% van de sites een goede INP, op desktop 97% (Web Almanac 2025). Het probleem zit dus vrijwel volledig bij mobiel, waar de processor trager is en JavaScript langer blokkeert.

Waarom is LCP de grootste bottleneck?

Van de drie metingen zakt LCP het vaakst. Op mobiel haalt 62% van de sites een goede LCP, tegenover 77% voor INP en 81% voor CLS. Alles bij elkaar haalt 48% van de mobiele sites en 56% van de desktopsites alle drie de drempels (Web Almanac 2025, CrUX-data van juli 2025).

LCP bestaat uit vier delen: de tijd tot de eerste byte van de server, de vertraging voordat de browser het LCP-bestand begint op te halen, de laadtijd van dat bestand, en de tijd tot het element getekend is. Google’s richtlijn is ongeveer 40% voor de server, 40% voor het laden, en minder dan 10% voor elk van de twee vertragingen (web.dev). Hoe dat in een webshop uitpakt, staat in Shopify-winkel sneller maken.

De twee praktische fixes die daaruit volgen: zet fetchpriority="high" op de afbeelding die waarschijnlijk je LCP-element is, en lazy-load die afbeelding nooit (web.dev). Zit het probleem bij de server, dan helpt geen enkele front-end truc en kijk je naar hosting aan de edge.

Hoe zit het met CLS en lettertypen?

De drempel van 0,1 staat vast. Wat vaak verkeerd begrepen wordt: CLS meet niet alleen de eerste seconden. Google groepeert layoutverschuivingen in sessievensters van maximaal 5 seconden, met minder dan 1 seconde tussen twee verschuivingen, en rapporteert het venster met de hoogste score over de hele levensduur van de pagina (web.dev). Een cookiebanner die na 8 seconden inschuift of een advertentie die laat laadt, telt dus gewoon mee.

De meest onderschatte oorzaak is een webfont dat inlaadt met font-display: swap en een andere breedte heeft dan het systeemfont waar het voor invalt. De hele tekst verspringt. De fix is size-adjust in je @font-face, waarmee je het fallback-font op dezelfde breedte zet als het webfont (web.dev).

Hoe meet je het goed?

Lighthouse en PageSpeed Insights draaien in een lab: één apparaat, één netwerk, geen echte gebruiker. De Chrome UX Report (CrUX) en het Core Web Vitals-rapport in Search Console gebruiken velddata van echte Chrome-bezoekers. Google zegt zelf: heb je beide, dan geeft velddata de prioriteit aan (web.dev).

Voor INP is dat geen keuze maar een noodzaak. Een labtest klikt nergens op, dus Lighthouse kan INP niet meten en gebruikt Total Blocking Time als benadering (web.dev). Wie zijn INP wil verbeteren, heeft echte gebruikersdata nodig en moet de traagste interacties opsporen.

Een praktische volgorde:

1. Lees het Core Web Vitals-rapport in Search Console en kijk welke URL-groepen op mobiel falen.
2. Pak eerst LCP: identificeer het LCP-element per paginatype en controleer de vier onderdelen.
3. Zoek de trage interacties voor INP met velddata, niet met Lighthouse.
4. Test layoutverschuivingen over de hele paginaduur, niet alleen bij het laden.

Wie dat structureel wil laten bewaken in plaats van eenmalig fixen, zit bij website onderhoud.

Veelgestelde vragen

Zijn Core Web Vitals een rankingfactor?

Ja, ze worden door Google’s rankingsystemen gebruikt. Google zegt er wel bij dat de meest relevante inhoud altijd voorgaat, ook als de page experience matig is. Zie het als een breekpunt tussen gelijkwaardige pagina’s, niet als de hoofdreden voor een ranking.

Wat is een goede INP-score?

200 milliseconden of minder op het 75e percentiel van je paginaweergaven. Tussen 200 en 500 ms is verbetering nodig, boven 500 ms is slecht. Op mobiel haalt ruim driekwart van de sites de drempel, op desktop bijna iedereen.

Waarom scoort mijn site goed in Lighthouse maar slecht in Search Console?

Lighthouse is een labtest op één apparaat en netwerk. Search Console gebruikt echte gebruikersdata uit Chrome, gemeten op het 75e percentiel. Trage telefoons en zwakke verbindingen van echte bezoekers zitten wel in de tweede meting en niet in de eerste.

Bronnen

1. Largest Contentful Paint (LCP), web.dev, Google, 2024
2. Interaction to Next Paint (INP), web.dev, Google, 2024
3. Cumulative Layout Shift (CLS), web.dev, Google, 2024
4. Interaction to Next Paint is officially a Core Web Vital, web.dev, Google, 2024
5. Web Almanac 2025: Performance, HTTP Archive, 2025
6. Understanding page experience in Google Search results, Google Search Central, 2025
7. More time, tools, and details on the page experience update, Google Search Central Blog, 2021
8. Optimize Largest Contentful Paint, web.dev, Google, 2024
9. CSS size-adjust for @font-face, web.dev, Google, 2021
10. Why lab and field data can be different, web.dev, Google, 2023