Core Web Vitals uitgelegd: LCP, INP en CLS

Core Web Vitals zijn drie meetwaarden waarmee Google de ervaring van echte gebruikers beschrijft: Largest Contentful Paint (LCP) voor het laden, Interaction to Next Paint (INP) voor de reactiesnelheid en Cumulative Layout Shift (CLS) voor visuele stabiliteit. Een pagina slaagt als minstens 75% van de bezoeken een LCP van 2,5 seconden of minder haalt, een INP van 200 milliseconden of minder en een CLS van 0,1 of minder. In deze gids lees je wat elke meetwaarde meet, hoe je je scores leest en welke verbeteringen ze meestal in beweging krijgen.

De drie meetwaarden in één oogopslag

Google publiceert vaste drempels per meetwaarde en deelt de resultaten in drie groepen in. De cijfers hieronder komen uit het overzicht van de Core Web Vitals op web.dev (Engelstalig).

Twee details zijn belangrijker dan de meeste mensen denken:

• Het 75e percentiel beslist. Google kijkt niet naar je snelste of je gemiddelde bezoek. Het neemt de waarde die 75% van de laadbeurten haalt of verbetert, apart voor mobiel en desktop. Een paar trage telefoons op zwakke verbindingen kunnen een pagina daardoor al naar "verbetering nodig" trekken.
• INP heeft in maart 2024 FID vervangen. First Input Delay mat alleen de vertraging voordat de eerste interactie werd afgehandeld. INP kijkt naar de latency van interacties tijdens het hele bezoek, en dat is een veel strengere test voor pagina's met veel JavaScript.

Velddata versus labdata

Als je een pagina test op corewebvitals.page, zie je twee soorten resultaten, en die spreken elkaar vaak tegen.

• Velddata (wat je echte gebruikers ervaren) komt uit het Chrome User Experience Report. Het gaat om echte Chrome-gebruikers over een doorlopende periode van 28 dagen. Dit is wat telt voor de beoordeling van de Core Web Vitals in Search Console.
• Labdata (de Lighthouse-score) is één gesimuleerde laadbeurt op een afgeknepen apparaat. Ideaal om te debuggen omdat het herhaalbaar is, maar INP kan het helemaal niet meten, want tijdens de test klikt niemand. Lighthouse gebruikt Total Blocking Time als ruwe vervanger.

Omdat velddata tot 28 dagen achterloopt, wordt een verbetering die je vandaag doorvoert pas geleidelijk zichtbaar. Bevestig met labtests dat de wijziging werkt en kijk daarna hoe de veldcijfers zich stabiliseren. Onze gids over websitesnelheid goed meten laat zien hoe je een voor-en-natest opzet waarop je kunt vertrouwen.

Zo verbeter je de LCP

LCP is vaak de moeilijkste van de drie om te halen, maar meestal het makkelijkst te diagnosticeren. Google deelt hem op in vier delen, beschreven in het LCP-artikel op web.dev (Engelstalig):

1. Time to First Byte: hoe lang de server nodig heeft om HTML te gaan versturen.
2. Resource load delay: de tijd tussen de eerste byte en het moment waarop de browser de LCP-afbeelding begint te laden.
3. Resource load duration: hoe lang het downloaden van de LCP-afbeelding zelf duurt.
4. Element render delay: de tijd tussen het binnenkomen van de afbeelding en het moment dat hij echt wordt getekend.

Kijk welk deel de overhand heeft voordat je iets verandert. Het paneel Performance in Chrome DevTools toont het LCP-element en hoe de tijd ervan is opgebouwd.

Trage serverrespons

Kost de TTFB alleen al een seconde of meer, dan kom je met geen enkele beeldoptimalisatie onder de 2,5 seconden. Veelvoorkomende oorzaken zijn ongecachete pagina's die bij elk verzoek door PHP en een database worden gegenereerd, een server ver weg van de meeste bezoekers, en trage plug-ins of extensies. Paginacaching, op de server of aan de edge, is de gebruikelijke oplossing. Zie TTFB verlagen voor de volledige lijst.

De LCP-afbeelding wordt laat ontdekt

Browsers vinden afbeeldingen tijdens het parsen van de HTML. Wordt je hero-afbeelding via een CSS-achtergrond ingesteld, door JavaScript ingevoegd of lazy geladen, dan hoort de browser er pas laat van. Oplossingen:

• Gebruik een gewoon <img>-element voor de hero-afbeelding.
• Zet nooit loading="lazy" op de LCP-afbeelding.
• Voeg fetchpriority="high" of een preload-hint toe, zodat de browser hem vroeg ophaalt:

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

De LCP-afbeelding is te zwaar

Een JPEG van 3000 pixels breed die op 1200 pixels wordt getoond, verspilt bij elk bezoek bandbreedte. Lever moderne formaten zoals WebP of AVIF, stem de afmetingen af op de lay-out en gebruik srcset voor verschillende schermen. Onze gids over afbeeldingen optimaliseren voor het web gaat hier uitgebreid op in.

Render-blokkerende CSS en fonts

Grote stylesheets en synchrone scripts in de <head> vertragen het tekenen, ook als de afbeelding al klaarstaat. Zet de kritieke CSS inline, stel niet-essentiële scripts uit en houd webfonts licht.

Zo verbeter je de INP

INP meet de tijd van een interactie van de gebruiker tot het volgende frame dat de browser tekent. Het is bijna altijd een JavaScript-probleem, geen netwerkprobleem. Het INP-artikel op web.dev deelt het op in input delay, verwerkingstijd en presentation delay.

Typische oorzaken en oplossingen:

• Lange taken op de main thread. Elk script dat langer dan 50 ms loopt, verhindert dat de pagina reageert. Knip lang werk op in kleinere stukken en geef tussendoor de controle terug aan de browser.
• Te veel JavaScript van derden. Chatwidgets, tagmanagers, A/B-testtools en advertentiescripts vechten allemaal om de main thread. Loop na wat er geladen wordt en verwijder wat niemand gebruikt.
• Zware event handlers. Een klik die een grote DOM-update veroorzaakt, een volledige productlijst opnieuw rendert of synchrone lay-outmetingen doet, voelt traag aan. Werk alleen bij wat veranderd is en geef direct visuele feedback voordat je het dure werk doet.
• Een enorme DOM. Pagina's met vele duizenden elementen hebben na elke interactie meer tijd nodig voor restyling en herberekening van de lay-out. Paginabouwers zijn een veelvoorkomende bron.

Een CDN of cache helpt de INP alleen indirect: minder downloadtijd betekent dat scripts eerder klaar zijn, maar de code moet nog steeds op het apparaat van de bezoeker draaien.

Zo verbeter je de CLS

CLS scoort de grootste reeks onverwachte layout shifts zolang de pagina open is. Verschuivingen binnen 500 ms na een interactie van de gebruiker tellen niet mee, dus een accordeon die na een klik openklapt is prima. Het CLS-artikel op web.dev legt de scoring uit.

De gebruikelijke verdachten:

• Afbeeldingen en video's zonder afmetingen. Zonder width- en height-attributen (of een CSS-aspect-ratio) reserveert de browser geen ruimte en duwt hij de inhoud omlaag zodra het bestand binnenkomt.
• Advertenties, embeds en banners die boven de inhoud worden ingevoegd. Reserveer er een vaste plek voor, of plaats ze onder de vouw.
• Cookiebanners die de pagina opzij duwen. Laat ze als overlay verschijnen in plaats van ze bovenaan het document in te voegen.
• Webfonts die ingewisseld worden. Wordt een fallbackfont vervangen door het webfont, dan kan tekst verspringen. font-display: swap houdt tekst vroeg zichtbaar; fallbackmetrics die overeenkomen (bijvoorbeeld met size-adjust) voorkomen dat de wissel dingen verschuift.

Hebben Core Web Vitals invloed op je ranking?

Core Web Vitals zijn onderdeel van de signalen voor paginagebruik van Google. Google stelt dat zijn rankingsystemen een goede paginabeleving belonen, maar ook dat relevantie en kwaliteit van de content voorop staan. In de praktijk tilt het halen van de Core Web Vitals een zwakke pagina niet naar de top, en laat het niet halen ervan een pagina die duidelijk het beste antwoord geeft niet zakken.

De betere reden om er aandacht aan te besteden, zijn je bezoekers. Traag laden, knoppen die haperen en verspringende lay-outs kosten je aanvragen en verkopen, wat een algoritme er ook van vindt. Zie de drempels als kwaliteitsnorm voor gebruikers, niet als SEO-trucje.

Zo helpt fast.site je

fast.site zit vóór je bestaande hosting, dus je houdt je host en je CMS. Je laat de nameservers van je domein naar fast.site wijzen, en daarna loopt je verkeer via een edge-netwerk met regio's in Noord-Amerika, Europa, Azië-Pacific en Zuid-Amerika, afhankelijk van je abonnement.

Voor de LCP levert de Fast Edge Cache™ gecachete pagina's en bestanden vanaf de edge die het dichtst bij de bezoeker ligt, zodat een cache HIT niet op je origin-server hoeft te wachten. Dat pakt het TTFB- en downloaddeel van de LCP aan. Beeldoptimalisatie zet JPEG en PNG direct om naar WebP voor browsers die dat ondersteunen, met AVIF afhankelijk van je abonnement.

De optionele schakelaar voor HTML-optimalisatie pakt veelvoorkomende LCP- en CLS-problemen direct aan: hij preloadt de gedetecteerde hero-afbeelding, voegt breedte en hoogte toe aan afbeeldingen om layout shift te beperken en voegt font-display: swap toe aan webfonts. De details staan in de documentatie over HTML-optimalisatie.

Traag JavaScript kan fast.site niet oplossen, dus het werk aan de INP blijft in je code. Meet voor en na op je eigen site: de header fs-cache toont HIT, MISS of BYPASS, en de analytics rapporteren TTFB en cache hit ratio. Je kunt dit allemaal testen met een gratis proefperiode van 7 dagen, zonder creditcard. Bekijk de abonnementen voor de details.

Veelgestelde vragen

Wat is een goede Core Web Vitals-score?

Een pagina slaagt als op het 75e percentiel van de bezoeken de LCP 2,5 seconden of minder is, de INP 200 milliseconden of minder en de CLS 0,1 of minder. Alle drie moeten "goed" zijn om voor de beoordeling te slagen. Mobiel en desktop worden apart beoordeeld.

Waarom is mijn PageSpeed-score goed, maar zak ik volgens Search Console?

De Lighthouse-score is één labtest op een gesimuleerd apparaat, terwijl Search Console 28 dagen aan gegevens van echte Chrome-gebruikers gebruikt. Echte bezoekers hebben tragere telefoons en netwerken dan de test, en labtests kunnen de INP niet meten. Vertrouw voor de beoordeling op de velddata en gebruik de labtest om te debuggen.

Hoe lang duurt het voordat verbeteringen in de Core Web Vitals zichtbaar zijn?

Velddata is een doorlopende periode van 28 dagen, dus verbeteringen worden in ongeveer vier weken geleidelijk zichtbaar. Search Console kan er iets langer over doen om de rapporten bij te werken. Labtests laten de wijziging meteen zien.

Verbetert een CDN de Core Web Vitals?

Een CDN helpt vooral de LCP, door de responstijd van de server en de downloadtijd te verlagen voor bezoekers ver van je origin. Het kan de CLS indirect verbeteren als het HTML-optimalisaties biedt, zoals het toevoegen van afmetingen aan afbeeldingen. De INP hangt vooral af van JavaScript in de browser, dus daar heeft een CDN weinig direct effect op.

Wat heeft First Input Delay (FID) vervangen?

Interaction to Next Paint (INP) heeft FID in maart 2024 vervangen als Core Web Vital. INP kijkt naar interacties tijdens het hele bezoek in plaats van alleen naar de eerste, en rekent ook de tijd mee die nodig is om het resultaat te tekenen.