Wat zijn Core Web Vitals?

Core Web Vitals zijn drie metrics van Google die meten hoe een pagina voor echte bezoekers aanvoelt: hoe snel de belangrijkste inhoud verschijnt, hoe snel de pagina reageert als je klikt of typt, en of de inhoud tijdens het laden niet verspringt. De drie metrics heten Largest Contentful Paint (LCP), Interaction to Next Paint (INP) en Cumulative Layout Shift (CLS).

Ze doen ertoe om twee redenen. Bezoekers haken af op een trage of springende pagina, en Google gebruikt Core Web Vitals als onderdeel van de page experience in Google Zoeken. Goede scores garanderen geen hogere positie, maar slechte scores kosten je wel gebruikservaring en conversie.

Hieronder lees je per metric wat er precies gemeten wordt, hoe je meet, welke waarden goed zijn en wat meestal de oorzaak is van een slechte score.

De drie metrics en hun drempelwaarden

Elke metric heeft drie zones: goed, verbeteren (needs improvement) en slecht (poor). Een pagina haalt de norm als alle drie de metrics op het 75e percentiel van de paginabezoeken in de zone goed vallen. Dat wordt apart bepaald voor mobiel en desktop.

Metric	Goed	Verbeteren	Slecht
LCP	≤ 2,5 s	> 2,5 s t/m 4 s	> 4 s
INP	≤ 200 ms	> 200 t/m 500 ms	> 500 ms
CLS	≤ 0,1	> 0,1 t/m 0,25	> 0,25

Het 75e percentiel betekent: sorteer alle gemeten bezoeken van snel naar traag en kijk naar de waarde waar 75% onder zit. Een gemiddelde zou een groep trage bezoeken op oude telefoons verbergen; het 75e percentiel doet dat minder.

INP is sinds 12 maart 2024 een Core Web Vital. Het verving toen First Input Delay (FID), dat alleen de vertraging van de eerste interactie mat. FID speelt in Google-tools geen rol meer.

Largest Contentful Paint (LCP)

Largest Contentful Paint meet de tijd vanaf het begin van de navigatie tot het grootste zichtbare inhoudselement in de viewport is gerenderd. Kandidaten zijn <img>-elementen, <image> binnen een <svg>, de posterafbeelding van een <video>, elementen met een background-image via url() en blokelementen met tekst. Zodra de bezoeker scrolt, klikt of typt, stopt de browser met het zoeken naar nieuwe kandidaten.

Waar de tijd naartoe gaat

LCP is op te splitsen in vier deeltijden. Daarmee zie je waar je moet ingrijpen:

Time to First Byte (TTFB)	server- en netwerktijd tot de eerste byte HTML
Resource load delay	tijd tot de browser de LCP-resource begint te laden
Resource load duration	downloadtijd van die resource
Element render delay	tijd tussen geladen resource en rendering

Belangrijkste oorzaken van een trage LCP

• een hoge TTFB door trage hosting, geen paginacache of veel redirects;
• een LCP-afbeelding die laat wordt ontdekt, bijvoorbeeld omdat ze via CSS of JavaScript wordt ingeladen, of omdat er loading="lazy" op staat;
• te grote afbeeldingen zonder moderne formaten (WebP, AVIF) of srcset;
• render-blocking CSS en JavaScript in de <head>;
• inhoud die pas na client-side rendering verschijnt.

Voor de LCP-afbeelding helpt het vaak om lazy loading weg te halen en de prioriteit te verhogen:

<img src="/hero.webp" width="1200" height="600"
     fetchpriority="high" alt="...">

Interaction to Next Paint (INP)

Interaction to Next Paint meet de reactiesnelheid over het hele bezoek. Voor elke klik, tik of toetsaanslag meet de browser de tijd tot het volgende frame wordt getekend. Scrollen en hoveren tellen niet mee. De INP van een bezoek is de traagste interactie; bij pagina's met veel interacties wordt per 50 interacties één uitschieter genegeerd.

Elke interactie bestaat uit drie delen:

Input delay	wachten tot de main thread vrij is
Processing duration	uitvoeren van de event handlers
Presentation delay	stijl, layout en paint van het volgende frame

Belangrijkste oorzaken van een slechte INP

• lange taken (long tasks) van meer dan 50 ms op de main thread, vaak door zware scripts van derden zoals tag-, chat- en advertentiescripts (minder tags in de browser kan met server-side tagging);
• event handlers die te veel synchroon werk doen;
• een grote DOM, waardoor layout en rendering na een wijziging lang duren;
• hydration van JavaScript-frameworks terwijl de bezoeker al interacteert.

De gebruikelijke aanpak is werk opknippen en de main thread tussendoor vrijgeven, zodat de browser eerst het volgende frame kan tekenen:

button.addEventListener('click', async () => {
  toonDirectFeedback();               // eerst zichtbare reactie
  await scheduler.yield?.() ?? new Promise(r => setTimeout(r, 0));
  zwaarWerk();                        // daarna de rest
});

Let op: scheduler.yield() wordt niet door elke browser ondersteund, daarom staat er een terugval met setTimeout.

Cumulative Layout Shift (CLS)

Cumulative Layout Shift meet onverwachte verschuivingen van zichtbare elementen. Elke verschuiving krijgt een score: de impact fraction (welk deel van de viewport is geraakt) maal de distance fraction (hoe ver het element is verschoven, ten opzichte van de viewport). Verschuivingen worden gegroepeerd in sessievensters: shifts met minder dan 1 seconde ertussen, tot maximaal 5 seconden per venster. CLS is de som van het venster met de hoogste score, gemeten over de hele levensduur van de pagina.

Verschuivingen binnen 500 ms na een klik, tik of toetsaanslag tellen niet mee, omdat de bezoeker die verwacht. Animaties met transform veroorzaken geen layout shift.

Belangrijkste oorzaken van een hoge CLS

• afbeeldingen, video's en iframes zonder width en height of aspect-ratio;
• advertenties, embeds en cookiebanners die ruimte innemen nadat de inhoud er al staat;
• webfonts die bij het wisselen een andere tekstmaat hebben;
• inhoud die via JavaScript boven bestaande inhoud wordt ingevoegd;
• animaties van top, left, width of height in plaats van transform.

/* Reserveer ruimte voor een embed */
.video-embed { aspect-ratio: 16 / 9; width: 100%; }

Core Web Vitals meten: veldgegevens en labdata

Core Web Vitals zijn in de eerste plaats veldgegevens (field data): metingen bij echte bezoekers op hun eigen apparaat en verbinding. Labdata zijn metingen in een gesimuleerde omgeving. Die zijn reproduceerbaar en handig tijdens het ontwikkelen, maar beoordelen doet Google op veldgegevens.

Bronnen van veldgegevens

• Chrome User Experience Report (CrUX): geanonimiseerde metingen van Chrome-gebruikers die daarvoor hebben gekozen, over een voortschrijdende periode van 28 dagen. Alleen pagina's en origins met genoeg verkeer komen erin;
• PageSpeed Insights: toont bovenaan de CrUX-gegevens van de URL of origin en daaronder een Lighthouse-test;
• het rapport Core Web Vitals in Search Console: groepeert vergelijkbare URL's en toont per groep de status voor mobiel en desktop, op basis van CrUX;
• de JavaScript-bibliotheek web-vitals: meet LCP, INP en CLS bij je eigen bezoekers, zodat je per pagina en per bezoek kunt analyseren (real-user monitoring);
• Chrome DevTools: het paneel Performance toont live LCP, INP en CLS van je eigen sessie en kan CrUX-gegevens ernaast zetten.

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

function stuurNaarAnalytics(metric) {
  // metric.name, metric.value, metric.rating, metric.id
  navigator.sendBeacon('/analytics', JSON.stringify(metric));
}

onLCP(stuurNaarAnalytics);
onINP(stuurNaarAnalytics);
onCLS(stuurNaarAnalytics);

Labdata in Lighthouse

Lighthouse laadt een pagina met een gesimuleerd apparaat en netwerk. Het meet LCP en CLS van het laden, maar geen INP, omdat er geen bezoeker klikt. Gebruik daar Total Blocking Time (TBT) als benadering. De Lighthouse-score is geen Core Web Vitals-beoordeling; een pagina kan in het lab 95 scoren en in het veld toch slecht zijn, of andersom.

Core Web Vitals verbeteren: waar je begint

Begin in Search Console of PageSpeed Insights om te zien welke metric op welk apparaattype faalt. Zoek de oorzaak daarna met DevTools en Lighthouse op een representatieve pagina. Na een verbetering duurt het tot 28 dagen voordat CrUX en Search Console het volledige effect laten zien. Wil je dat iemand de oorzaken opspoort en oplost, kijk dan bij website-onderhoud.

Houd er rekening mee dat veldgegevens alleen Chrome-bezoekers in CrUX omvatten. Heb je veel Safari-verkeer, dan geeft eigen meting met web-vitals een vollediger beeld. Sinds Safari 26.2 meet je daar ook LCP en INP; CLS is in Safari nog niet meetbaar.

Bronnen

• https://web.dev/articles/vitals
• https://web.dev/articles/lcp
• https://web.dev/articles/inp
• https://web.dev/articles/cls
• https://developers.google.com/search/docs/appearance/core-web-vitals
• https://developers.google.com/search/blog/2023/05/introducing-inp
• https://web.dev/blog/lcp-and-inp-are-now-baseline-newly-available
• https://github.com/GoogleChrome/web-vitals