Core Web Vitals in 2026: de huidige metrics
De huidige Core Web Vitals zijn LCP, INP en CLS. LCP meet laadprestatie, INP interactierespons en CLS visuele stabiliteit. Google beschrijft ze als centrale, gebruikersgerichte aspecten van echte pagina-ervaring. [1][3]
FID hoort niet meer bij de huidige set. INP verving FID in maart 2024 en FID werd later uit CrUX verwijderd. [7][14]
Drempels en het 75e percentiel
| Metric | Goed | Verbetering nodig | Slecht | Meet |
|---|---|---|---|---|
| LCP | ≤ 2.5 s | 2.5 s - 4.0 s | > 4.0 s | Laden van hoofdcontent |
| INP | ≤ 200 ms | 200 ms - 500 ms | > 500 ms | Interactierespons |
| CLS | ≤ 0.1 | 0.1 - 0.25 | > 0.25 | Visuele stabiliteit |
Goed betekent LCP ≤ 2,5 s, INP ≤ 200 ms en CLS ≤ 0,1. Verbetering nodig: 2,5 tot 4,0 s, 200 tot 500 ms en 0,1 tot 0,25. Daarboven is slecht. [3][4]
Google gebruikt het 75e percentiel, niet het gemiddelde. Minstens 75% van de ervaringen moet de drempel halen of beter doen. Mobile en desktop worden apart bekeken. [3][4]
Alle drie metrics moeten goed zijn om de totale beoordeling te halen. [3]
Core Web Vitals en SEO
Google bevestigt dat Core Web Vitals in ranking-systemen wordt gebruikt als onderdeel van pagina-ervaring. Goede scores garanderen geen hoge positie, omdat relevantie en inhoudskwaliteit belangrijk blijven. [1][2]
Optimalisatie verbetert dus echte gebruikerservaring en verwijdert een technische zwakte, maar vervangt geen goede content.
LCP: wat er echt wordt gemeten
Largest Contentful Paint meet vanaf het begin van navigatie tot het grootste geschikte content-element in de viewport is gerenderd. In velddata kan LCP ook redirects, verbindingsopbouw en TTFB bevatten. [5]
LCP is daarom niet simpelweg de downloadtijd van de grootste afbeelding. Vertraging kan veel eerder in de laadketen ontstaan. [5][6]
LCP in de praktijk: vier onderdelen
web.dev splitst LCP in TTFB, resource load delay, resource load duration en element render delay. [6]
Als de LCP-resource laat wordt ontdekt, kan compressie alleen weinig helpen. De resource moet waar mogelijk vroeg in de initiële HTML zichtbaar zijn en een LCP-afbeelding hoort niet lazy geladen te worden. Prioriteit of preload kan helpen. [6]
Diagnoseer in deze volgorde: TTFB, ontdekking van de resource, transferduur en rendervertraging. [6]
- Verlaag TTFB met cache, CDN, minder redirects en snellere backend.
- Maak de LCP-resource zichtbaar in initiële HTML.
- Gebruik geen `loading="lazy"` voor de LCP-afbeelding.
- Gebruik geschikte prioriteit of preload bij late ontdekking.
- Optimaliseer afbeeldingsgrootte en formaat alleen als transfer echt het knelpunt is.
- Verminder JavaScript of CSS die final rendering blokkeert.
INP: responsiviteit over de hele sessie
Interaction to Next Paint observeert clicks, taps en toetsenbordinteracties tijdens de hele sessie. Voor de meeste pagina's wordt de traagste interactie gerapporteerd. Bij veel interacties wordt één slechtste interactie per 50 genegeerd om uitschieters te beperken. [7]
INP verschilt van FID omdat het input delay, verwerking en tijd tot de volgende paint omvat. [7][8]
Zonder click, tap of toetsenbord kan een bezoek geen INP hebben. Scrollen en hover tellen niet mee. [7]
INP in de praktijk: drie bronnen van vertraging
Totale interactielatentie bestaat uit input delay, processing duration en presentation delay. Slechte INP kan dus komen door een drukke main thread, trage handlers of duur layout- en renderwerk. [8]
Veelvoorkomende verbeteringen zijn kortere taken, werk opsplitsen, minder zwaar JavaScript, eenvoudiger layout, Web Workers waar passend en snel visueel feedback geven. [8]
Begin met RUM-data die de trage interactie identificeert en reproduceer die daarna in DevTools. Lighthouse alleen vertegenwoordigt geen volledige echte INP. [8][11][12]
CLS: visuele stabiliteit tijdens de hele paginalevensduur
Cumulative Layout Shift meet onverwachte beweging van zichtbare elementen. Het gebruikt het grootste sessievenster waarin opeenvolgende shifts minder dan één seconde uit elkaar liggen en het hele venster maximaal vijf seconden duurt. [9]
CLS is dimensieloos en combineert impact en bewegingsafstand. Sommige direct door gebruikersactie veroorzaakte veranderingen kunnen worden uitgesloten. [9]
Problemen ontstaan vaak na load door advertenties, banners, widgets of fonts. Een enkele lab-load kan ze missen. [10][11]
CLS in de praktijk: veelvoorkomende oorzaken
web.dev noemt afbeeldingen zonder afmetingen, advertenties, embeds en iframes zonder gereserveerde ruimte, dynamisch ingevoegde content en webfonts als typische oorzaken. [10]
Reserveer ruimte voordat content verschijnt. Gebruik `width` en `height` of stabiel `aspect-ratio`, geef advertenties en embeds voorspelbare afmetingen en voeg geen content boven reeds gelezen content in. [10]
Bij fonts moet het verschil tussen fallback en definitief font worden beperkt en echt gemeten. `font-display` alleen lost niet ieder CLS-probleem op. [10]
Velddata versus labdata
Core Web Vitals zijn primair veldmetrics. CrUX en eigen RUM tonen echte gebruikers, Lighthouse helpt om problemen gecontroleerd te reproduceren en debuggen. [11][12]
Lighthouse meet geen volledige natuurlijke INP en gebruikt onder andere TBT als labproxy. Lab-CLS kan ook lager zijn wanneer shifts pas na interacties ontstaan. [11][12]
Gebruik velddata om vast te stellen of er een echt probleem is en labtools om de oorzaak te vinden.
Welk gereedschap waarvoor
| Tool | Datatype | Beste gebruik |
|---|---|---|
| PageSpeed Insights | CrUX + Lighthouse | Snelle URL- en origincheck |
| Search Console | CrUX, URL-groepen | Pagina-groepen met SEO-problemen vinden |
| Chrome DevTools | Lab + CrUX-context | Gedetailleerde diagnose van LCP, INP en CLS |
| Lighthouse | Lab | Automatische audits en CI-regressies |
| RUM / web-vitals | Eigen gebruikersdata | Nauwkeurigste monitoring na releases |
PageSpeed Insights combineert CrUX en Lighthouse. Search Console groepeert vergelijkbare URL's. DevTools biedt live metrics en gedetailleerde traces. [12][13]
CrUX API en PageSpeed Insights gebruiken effectief een rollend venster van ongeveer 28 dagen. Een recente fix verandert de publieke p75 dus niet direct. Eigen RUM laat impact sneller zien. [12][13]
Een goede workflow gebruikt RUM voor monitoring, Search Console voor SEO-groepen, PSI voor snelle checks en DevTools voor diagnose.
CrUX in 2026: recente staat van het web
| Metric | Origins met goede score, juli 2026 |
|---|---|
| LCP | 68,3% |
| INP | 85,7% |
| CLS | 81,6% |
| Alle Core Web Vitals | 55,7% |
De laatste maanddataset die vóór 4 september 2026 is gepubliceerd betreft juli 2026 en verscheen op 11 augustus. Er zijn 18.059.068 origins. 68,3% had goede LCP, 81,6% goede CLS, 85,7% goede INP en 55,7% slaagde voor alle Core Web Vitals. [14]
Dit zijn geaggregeerde cijfers voor het web dat in CrUX is vertegenwoordigd, geen doelen voor één site. CrUX vereist onder andere publieke vindbaarheid en voldoende populariteit. [13][14]
Ontbrekende CrUX-data betekent niet snel of traag, maar onvoldoende in aanmerking komende gegevens.
SPA's en soft navigations: belangrijke verandering in 2026
Historisch waren Core Web Vitals sterk gericht op volledige documentnavigaties. Chrome 151 introduceerde in 2026 nieuwe API's voor soft navigations en de documentatie werd op 2 september 2026 bijgewerkt. [15]
Chrome DevTools 152, uitgebracht op 25 augustus 2026, toont Core Web Vitals voor soft navigations standaard in Live Metrics via `web-vitals` 6.0.0. [16]
Dit is belangrijk voor React, Angular, Vue en andere SPA's. Ga er niet automatisch van uit dat alle publieke CrUX-rapporten soft navigations al identiek behandelen.
Productiemonitoring met context
Een publieke p75 zegt vaak dat er een probleem is, maar niet waarom. Eigen RUM kan LCP-element en onderdelen, INP-interactie, route, apparaat en appversie meesturen. web.dev adviseert RUM als aanvulling op CrUX. [3][8][12]
Label deployments met versies en vergelijk verdelingen voor en na wijzigingen. Gemiddelden kunnen regressies op tragere apparaten verbergen.
CI voorkomt duidelijke labregressies, maar vervangt geen productiemonitoring. [11][12]
Praktisch verbeterplan
Bepaal eerst welke metric op p75 faalt en bij welke paginatypen. Beperk het probleem met RUM of CrUX, reproduceer het in DevTools, herstel de concrete oorzaak en monitor na deployment. [12]
Zoek voor LCP het dominante onderdeel, voor INP de echte trage interactie en voor CLS de concrete shifts.
Controleer daarna lab- en velddata. Publieke CrUX-data loopt achter, waardoor eigen RUM belangrijk is voor snelle validatie.
- Identificeer het probleem eerst in velddata.
- Splits mobile en desktop.
- Voor LCP: TTFB, ontdekking, transfer en rendervertraging.
- Voor INP: de interactie en drie latentieonderdelen.
- Voor CLS: shifts gedurende de hele sessie.
- Rol één meetbare verbetering uit en vergelijk voor en na.
- Houd RUM en regressie-alerts actief.
