Core Web Vitals uitgelegd: LCP, INP en CLS in gewone taal

Core Web Vitals zijn geen persoonlijkheidstest voor je website

Core Web Vitals worden vaak behandeld als een mysterieuze scorekaart. Een pagina krijgt een rood getal, iemand plaatst een screenshot in Slack en het team begint te discussiëren over JavaScript-frameworks.

Dat is niet bijzonder nuttig.

Een betere manier om naar Core Web Vitals te kijken is eenvoudiger: het zijn drie metingen die aangeven of een pagina bruikbaar aanvoelt voor een echte persoon op een echt apparaat. Ze vangen niet elk aspect van performance, toegankelijkheid of kwaliteit. Maar ze signaleren wel drie veelvoorkomende bronnen van frustratie:

• De hoofdinhoud verschijnt te langzaam.
• De pagina reageert traag wanneer de gebruiker iets probeert te doen.
• De lay-out verspringt terwijl de gebruiker leest of tikt.

Dat zijn de drie Core Web Vitals: LCP, INP en CLS.

Google gebruikt ze als onderdeel van zijn page experience-signalen, maar de SEO-invalshoek is niet de beste reden om je ermee bezig te houden. De betere reden is dat trage, springerige en niet-reagerende pagina’s tijd van gebruikers verspillen. Ze converteren meestal ook slechter, veroorzaken meer supportvragen en verouderen slecht.

De drie statistieken in één zin elk

Voordat we de details ingaan, is dit de versie in gewone taal:

• LCP, of Largest Contentful Paint, meet hoe lang het duurt voordat de belangrijkste zichtbare inhoud is geladen.
• INP, of Interaction to Next Paint, meet hoe snel de pagina tijdens het bezoek reageert op gebruikersinteracties.
• CLS, of Cumulative Layout Shift, meet hoeveel de pagina onverwacht verschuift.

De gebruikelijke drempelwaarden zijn:

| Statistiek | Goed | Moet beter | Slecht | |---|---:|---:|---:| | LCP | 2,5 s of sneller | 2,5 s–4,0 s | Meer dan 4,0 s | | INP | 200 ms of sneller | 200 ms–500 ms | Meer dan 500 ms | | CLS | 0,1 of lager | 0,1–0,25 | Meer dan 0,25 |

Deze cijfers worden normaal beoordeeld op het 75e percentiel van echte gebruikersbezoeken. Dat is belangrijk. Je probeert niet één perfecte labrun te maken. Je probeert de ervaring goed te maken voor de meeste gebruikers, inclusief mensen met tragere telefoons en rommeligere netwerken.

Als je naar een geautomatiseerd rapport kijkt en niet weet waar je moet beginnen, helpt het om diagnose van paniek te scheiden. We hebben een aparte gids over hoe je een Lighthouse-rapport leest zonder in paniek te raken, waarin die workflow uitgebreider wordt behandeld.

LCP: wanneer voelt de pagina geladen?

Largest Contentful Paint meet de rendertijd van het grootste zichtbare contentelement in de viewport. In de praktijk is dat vaak:

• een hero-afbeelding,
• een grote kop,
• een uitgelichte artikelafbeelding,
• een productafbeelding,
• een groot tekstblok.

LCP vraagt niet wanneer elk script, elke trackingpixel en elke afbeelding onder de vouw klaar was met laden. Het vraagt: wanneer werd het belangrijkste element zichtbaar waarvoor de gebruiker kwam?

Dat maakt LCP een menselijkere statistiek dan ouderwetse “page load time”. Een pagina kan technisch gezien laat klaar zijn met laden en toch snel aanvoelen als de hoofdinhoud snel verschijnt. Het omgekeerde is ook waar: een pagina kan het load-event afvuren terwijl het hero-gedeelte nog leeg, wazig of geblokkeerd is door rendervertraging.

Veelvoorkomende oorzaken van slechte LCP

De meeste slechte LCP-problemen komen uit een paar voorspelbare hoeken:

1. Trage serverrespons

Als het HTML-document laat arriveert, begint al het andere ook laat.

1. Renderblokkerende CSS of JavaScript

De browser heeft de inhoud, maar kan die nog niet schilderen.

1. Niet-geoptimaliseerde hero-afbeeldingen

Het grootste element is te groot, heeft het verkeerde formaat, krijgt geen prioriteit of wordt per ongeluk lazy-loaded.

1. Webfonts die tekstrendering vertragen

Een grote kop kan het LCP-element zijn, en het laden van fonts kan die vertragen of visueel veranderen.

1. Vertraging door client-side rendering

Als de pagina een grote JavaScript-bundel nodig heeft voordat betekenisvolle inhoud kan worden getoond, lijdt LCP daaronder.

Hoe je LCP verbetert

Begin met het daadwerkelijke LCP-element. Optimaliseer geen willekeurige assets voordat je weet wat de browser meet.

Praktische oplossingen zijn onder meer:

• Serveer HTML snel: cache waar passend, verminder backendwerk en voorkom trage redirects.
• Optimaliseer de LCP-afbeelding: gebruik de juiste afmetingen, compressie en indeling.
• Lazy-load de hero-afbeelding boven de vouw niet.
• Gebruik fetchpriority="high" zorgvuldig voor de hoofdafbeelding wanneer die echt de prioriteit is.
• Inline kritieke CSS alleen wanneer dat de rendervertraging merkbaar vermindert.
• Verminder de JavaScript die nodig is vóór de eerste betekenisvolle render.
• Gebruik font-display: swap of een andere bewuste fontstrategie.

Afbeeldingen en fonts zijn vaak de boosdoeners. Bij afbeeldingen gaat de afweging niet alleen over “klein bestand goed”. Formaatkeuze, encoding-inspanning en browserondersteuning tellen allemaal mee. Daarom houden we een praktische beslisboom bij voor wanneer AVIF beter is dan WebP en wanneer niet. Voor pagina’s met veel tekst zijn webfonts nog steeds een van de makkelijkste performancewinsten, omdat veel sites meer fontbestanden leveren dan ze gebruiken.

INP: reageert de pagina wanneer je hem aanraakt?

Interaction to Next Paint meet responsiviteit. Specifieker: het kijkt naar de vertraging tussen een gebruikersinteractie en de volgende visuele update nadat de browser die interactie heeft verwerkt.

Interacties zijn bijvoorbeeld:

• op een knop klikken,
• op een menu tikken,
• een selectievakje aanvinken,
• typen in een formulierveld,
• een accordion openen.

INP verving First Input Delay als Core Web Vital in 2024. Dat was een goede verandering. First Input Delay keek alleen naar de eerste interactie. INP is breder: het kijkt naar interacties gedurende het hele paginabezoek en rapporteert een interactie met hoge latency als de responsiviteitsscore van de pagina.

In gewone taal: INP vindt pagina’s die geladen lijken, maar vast aanvoelen.

Je hebt waarschijnlijk zo’n pagina gebruikt. Hij lijkt klaar. Je tikt op het menu. Een halve seconde gebeurt er niets. Je tikt nog eens. Daarna gebeuren er twee dingen tegelijk. Dat is een INP-probleem.

Veelvoorkomende oorzaken van slechte INP

INP is meestal een main-thread-probleem. De browser wil reageren, maar JavaScript, renderwerk of lay-outberekening zit in de weg.

Typische oorzaken zijn:

• grote JavaScript-bundels,
• dure eventhandlers,
• hydratiewerk in client-rendered apps,
• scripts van derden die concurreren om de main thread,
• langlopende taken na paginalaad,
• complexe DOM-updates die door kleine interacties worden veroorzaakt,
• layout thrashing, waarbij code herhaaldelijk lay-outwaarden leest en schrijft.

Marketingtags, analytics, chatwidgets en consentbanners kunnen allemaal bijdragen. Dat betekent niet “verwijder alles”. Het betekent dat elk script op de pagina kosten heeft, en interactielatency is waar die kosten vaak zichtbaar worden.

Hoe je INP verbetert

INP verbeteren gaat minder over één magisch attribuut en meer over het verminderen van concurrentie op de main thread.

Nuttige aanpakken zijn onder meer:

• Breek lange JavaScript-taken op in kleinere stukken.
• Stel niet-essentieel werk uit tot nadat de pagina bruikbaar is.
• Verwijder ongebruikte JavaScript in plaats van die alleen te minificeren.
• Houd eventhandlers klein en voorspelbaar.
• Vermijd het opnieuw renderen van grote delen van de interface voor kleine statuswijzigingen.
• Gebruik waar mogelijk CSS voor eenvoudige visuele states.
• Audit scripts van derden en laad ze alleen waar ze nodig zijn.

Kijk ook naar interactieontwerp. Een knop die direct visuele feedback geeft, kan responsiever aanvoelen, ook als vervolgwerk langer duurt. Dat is geen vervanging voor performance, maar wel onderdeel van goede interface-engineering. Onze checklist voor toegankelijke webknoppen overlapt hiermee: duidelijke states, juiste semantiek en voorspelbaar gedrag helpen zowel gebruikers als browsers.

CLS: blijft de pagina waar de gebruiker hem verwacht?

Cumulative Layout Shift meet onverwachte verplaatsing van zichtbare elementen. Als een gebruiker een alinea begint te lezen en een advertentie, afbeelding of banner erboven laadt waardoor de tekst naar beneden wordt geduwd, draagt dat bij aan CLS.

CLS wordt niet in seconden gemeten. Het is een score op basis van hoeveel inhoud bewoog en hoe ver die bewoog. Lager is beter.

Het sleutelwoord is onverwacht. Lay-outwijzigingen die door een gebruikersactie worden veroorzaakt, worden meestal niet op dezelfde manier meegeteld. Als iemand op “meer tonen” tikt en inhoud uitklapt, is dat verwacht. Als een nieuwsbriefbanner na drie seconden bovenaan verschijnt en alles naar beneden duwt, is dat niet verwacht.

Veelvoorkomende oorzaken van slechte CLS

CLS-fouten zijn vaak alledaags:

• afbeeldingen zonder width- en height-attributen,
• advertenties of embeds zonder gereserveerde ruimte,
• cookiebanners die boven inhoud worden ingevoegd,
• webfonts die wisselen met andere metriek,
• laat ladende promotiebalken,
• dynamisch ingevoegde inhoud dicht bij de bovenkant van de pagina.

De oplossing is meestal om ruimte te reserveren voordat de inhoud arriveert. De browser moet zo vroeg mogelijk de vorm van de pagina kennen.

Hoe je CLS verbetert

Begin met de zichtbare verschuivingen. Bekijk een opname of gebruik browsertools om te bepalen welke elementen bewegen.

Pas daarna de saaie oplossingen toe:

• Voeg expliciete width- en height-attributen toe aan afbeeldingen.
• Gebruik CSS aspect-ratio voor responsieve mediacontainers.
• Reserveer vaste of minimale ruimte voor advertenties, embeds en iframes.
• Vermijd het invoegen van banners boven bestaande inhoud na het laden.
• Kies fontfallbacks met vergelijkbare metriek als het uiteindelijke font.
• Vermijd animaties die lay-outeigenschappen zoals top, left, width of height veranderen; geef de voorkeur aan transforms.

CLS is een van de weinige performancestatistieken waarbij discipline het wint van slimheid. Als de pagina stabiele vakken heeft, scoort hij meestal goed.

Field data en lab data zijn allebei nuttig, maar beantwoorden verschillende vragen

Een veelvoorkomende bron van verwarring is dat verschillende tools verschillende cijfers tonen. Dat is normaal.

Field data komt van echte gebruikers. Het weerspiegelt echte apparaten, netwerken, locaties en browseromstandigheden. Google’s Chrome User Experience Report is een voorbeeld van field data.

Lab data komt uit een gecontroleerde testomgeving. Lighthouse is het bekende voorbeeld. Het is herhaalbaar en nuttig voor debugging, maar het is niet hetzelfde als de geleefde ervaring van je gebruikers.

Gebruik field data om te bepalen of gebruikers een echt probleem hebben. Gebruik lab data om dat probleem te reproduceren en te debuggen.

Onthoud ook dat Core Web Vitals meestal per URL of URL-groep worden beoordeeld, niet als één abstracte eigenschap van je merk. Je homepage, blogartikel, prijspagina en checkout kunnen heel verschillende bottlenecks hebben.

Een verstandige werkvolgorde

Als alle drie de statistieken slecht zijn, is de verleiding groot om overal tegelijk te beginnen. Weersta die verleiding.

Een praktische volgorde is:

1. Los eerst duidelijke CLS-problemen op

Ontbrekende afbeeldingsafmetingen en instabiele banners zijn vaak snelle winsten.

1. Verbeter LCP voor belangrijke templates

Richt je op pagina’s die ertoe doen: productpagina’s, landingspagina’s, artikelen en registratieflows.

1. Onderzoek INP met echte interacties

Klik op de dingen waar gebruikers echt op klikken. Menu’s, filters, formulieren en checkoutbediening laten vaak meer zien dan de eerste laadtrace.

1. Audit scripts van derden

Behoud de scripts die hun kosten rechtvaardigen. Verwijder of vertraag de scripts die dat niet doen.

1. Stel een performancebudget in

Zonder budget brokkelen performanceverbeteringen af. Nieuwe scripts, afbeeldingen en designcomponenten maken het werk stilletjes ongedaan.

Het belangrijke punt: optimaliseer niet voor een badge. Optimaliseer voor de gebruikersreis. Een marginale scoreverbetering op een pagina met weinig verkeer kan minder belangrijk zijn dan een iets imperfecte maar veel snellere checkoutinteractie.

<!-- tool-cta:start -->

💡 Probeer dit: Omdat LCP meestal een afbeeldingsprobleem is, verklein je je hero-asset met Image Compressor als eerste eenvoudige winst.

<!-- tool-cta:end -->

Wat Core Web Vitals je niet vertellen

Core Web Vitals zijn nuttig, maar onvolledig.

Ze vertellen je niet of je content goed is. Ze vertellen je niet of je navigatie logisch is. Ze garanderen geen toegankelijkheid. Ze meten geen privacy, beveiliging, vertrouwen, leesbaarheid of of de pagina de vraag van de gebruiker beantwoordt.

Ze vervangen ook geen beoordelingsvermogen. Een pagina kan slagen voor Core Web Vitals en toch onaangenaam zijn. Een complexe applicatie kan een drempel missen en toch verantwoord zijn gebouwd binnen haar beperkingen.

Behandel LCP, INP en CLS als rookmelders. Als ze afgaan, onderzoek dan wat er aan de hand is. Als ze stil zijn, blijf het gebouw onderhouden.