Core Web Vitals laten zien hoe snel, soepel en stabiel een website aanvoelt voor echte bezoekers. Je leest wat LCP, INP en CLS precies meten, hoe je de scores interpreteert en welke technische of inhoudelijke keuzes vaak voor problemen zorgen.
Wat Core Web Vitals meten en hoe je scores leest
Core Web Vitals zijn drie prestatiemaatstaven die Google gebruikt om onderdelen van de gebruikerservaring te beoordelen: laadsnelheid, reactiesnelheid en visuele stabiliteit. Ze heten Largest Contentful Paint (LCP), Interaction to Next Paint (INP) en Cumulative Layout Shift (CLS). Samen geven ze geen compleet oordeel over een website, maar ze maken wel zichtbaar waar een bezoeker mogelijk moet wachten, herhalen of zijn plek kwijtraakt. Een snelle score betekent bovendien niet automatisch dat de inhoud bruikbaar is of dat een taak eenvoudig uit te voeren is.
De gebruikelijke grenzen voor een goede ervaring zijn een LCP van maximaal 2,5 seconden, een INP van maximaal 200 milliseconden en een CLS-score van maximaal 0,1. Google beoordeelt deze waarden op het 75e percentiel van echte bezoeken. Dat betekent dat minstens driekwart van de gemeten bezoeken aan de grens moet voldoen. Een gemiddelde kan problemen bij een flink deel van de bezoekers verbergen: een paar zeer snelle bezoeken trekken dat gemiddelde omlaag.
Voor een betekenisvolle interpretatie moet je daarom kijken naar mobiel en desktop, naar verschillende paginatypen en naar de verdeling van scores. Een productpagina met een grote galerij gedraagt zich anders dan een eenvoudige contactpagina. Ook netwerk, apparaat en browser spelen mee. De cijfers beschrijven ervaring onder echte omstandigheden; ze zijn geen vaste eigenschap van een website die voor iedere bezoeker hetzelfde uitpakt.
Largest Contentful Paint: wanneer laadt de hoofdinhoud?
Largest Contentful Paint meet hoe lang het duurt voordat het grootste zichtbare inhoudselement in het eerste scherm verschijnt. Dat element is vaak een grote afbeelding, een productfoto, een videoposter of een blok tekst. De meting begint wanneer de pagina wordt geopend en eindigt zodra de browser dat element heeft getoond. LCP is daarmee een praktische benadering van het moment waarop een bezoeker het gevoel krijgt dat de belangrijkste inhoud beschikbaar is. Het is niet hetzelfde als de volledige laadtijd: onderdelen onderaan de pagina kunnen nog bezig zijn.
Een goede LCP is maximaal 2,5 seconden. Een waarde tussen 2,5 en 4 seconden vraagt aandacht; boven 4 seconden is de ervaring doorgaans traag. Die tijd bestaat uit verschillende stappen: de server moet reageren, de browser moet het relevante bestand ontdekken en downloaden, en daarna moet het element worden weergegeven. Als een grote afbeelding pas na het laden van JavaScript wordt toegevoegd, begint de download bijvoorbeeld laat. Een snelle server alleen lost dat niet op.
De identiteit van het LCP-element kan per pagina verschillen en tijdens het laden veranderen. Eerst kan een kop de grootste kandidaat zijn, waarna een afbeelding die plek overneemt. Daarom is het nuttig om in meetgegevens te controleren welk element de score bepaalt. Een ontwerpkeuze als een beeldvullende banner maakt een grote afbeelding waarschijnlijker als LCP-element, terwijl een tekstgerichte pagina vooral afhankelijk kan zijn van serverreactie, lettertypen en CSS. De juiste diagnose begint dus bij de pagina zelf, niet bij een algemene aanname over afbeeldingen.
Waarom afbeeldingen, scripts en servers LCP verslechteren
Grote afbeeldingen zijn een veelvoorkomende oorzaak van een hoge LCP, vooral wanneer een zware foto als achtergrond is ingesteld of een afbeelding groter wordt geleverd dan het scherm nodig heeft. Een bestand van meerdere megabytes moet langer worden gedownload, zeker op mobiele netwerken. Lever daarom passende formaten en afmetingen, bijvoorbeeld met moderne afbeeldingsformaten en responsieve varianten. Comprimeren helpt, maar te sterke compressie maakt productdetails of tekst in beelden zichtbaar onscherp. De afweging is niet alleen bestandsgrootte: het beeld moet ook op het juiste moment beschikbaar zijn.
Een LCP-afbeelding die met lazy loading wordt uitgesteld, kan pas laat worden aangevraagd. Lazy loading is nuttig voor afbeeldingen buiten het eerste scherm, maar doorgaans ongeschikt voor het belangrijkste zichtbare beeld. Ook kan een afbeelding verborgen zitten achter een JavaScript-component, waardoor de browser de URL later ontdekt dan nodig. CSS-achtergrondafbeeldingen worden bijvoorbeeld vaak later gevonden dan afbeeldingen die direct in de HTML staan. Voor het LCP-element kan het helpen om de browser vroeg te laten weten dat het belangrijk is, maar een prioriteit voor te veel bestanden zorgt juist voor concurrentie om bandbreedte.
Daarnaast telt de tijd vóór het downloaden. Een trage serverreactie, omleidingen, niet-gecachete pagina’s of een externe API die de weergave blokkeert, stellen alle inhoud uit. Renderblokkerende CSS en scripts kunnen ervoor zorgen dat een gedownloade afbeelding toch niet direct verschijnt. De oplossing hangt af van het knelpunt: optimaliseer de server als de HTML laat aankomt, de afbeeldingslevering als het bestand traag is en de kritieke CSS of JavaScript als de browser de inhoud niet op tijd kan tekenen. Blind afbeeldingen comprimeren helpt weinig wanneer de server de grootste vertraging veroorzaakt.
Interaction to Next Paint: meetlat voor reactiesnelheid
Interaction to Next Paint meet hoe snel een pagina visueel reageert op interacties zoals klikken, tikken en toetsenbordinput. De meting loopt vanaf het moment dat de gebruiker een interactie uitvoert tot het volgende frame waarin de browser de update kan tonen. INP kijkt gedurende het bezoek naar interacties en gebruikt een representatieve hoge waarde, zodat een terugkerende trage handeling niet verdwijnt achter veel snelle klikken. Op pagina’s met weinig interactie kan er onvoldoende meetmateriaal zijn; dat betekent niet automatisch dat de bediening optimaal is.
Een INP tot en met 200 milliseconden geldt als goed. Tussen 200 en 500 milliseconden is verbetering wenselijk en boven 500 milliseconden is de respons traag. De vertraging kan ontstaan vóór de gebeurtenisafhandeling, tijdens de JavaScript-code die op de interactie reageert of bij het tekenen van de bijgewerkte pagina. Een knop kan dus traag aanvoelen hoewel de klik zelf direct wordt geregistreerd: de browser is mogelijk bezig met een lange taak en kan de visuele reactie niet snel tonen.
INP verving First Input Delay in maart 2024 als Core Web Vital. FID keek alleen naar de vertraging bij de eerste interactie en miste onder meer de verwerking en de daaropvolgende weergave. INP geeft een breder beeld van de hele interactie-ervaring. Dat verschil is belangrijk bij pagina’s waar bezoekers eerst scrollen, daarna filters openen en vervolgens een product aan hun winkelwagen toevoegen. De eerste klik kan snel zijn, terwijl een latere filteractie vastloopt. Voor een bruikbare diagnose moet je daarom weten welke interactie op welke pagina traag is, in plaats van alleen naar één totaalcijfer te kijken.
JavaScript, lange taken en externe tools vertragen INP
De browser voert veel JavaScript-taken uit op de hoofdthread, die ook nodig is om invoer te verwerken en nieuwe beelden te tekenen. Een lange taak kan daardoor een klik laten wachten, zelfs als die taak niet direct bij de knop hoort. Grote scripts, omvangrijke framework-bundels, complexe berekeningen en het verwerken van veel productresultaten zijn bekende oorzaken. Ook scripts voor analytics, advertenties, chat, personalisatie of reviews kunnen beslag leggen op dezelfde middelen. Een externe tool hoeft niet zichtbaar te zijn om de bediening te vertragen.
Een veelgebruikte aanpak is onnodige code verwijderen, functionaliteit pas laden wanneer die nodig is en lange taken opsplitsen in kleinere stukken. Dat vraagt keuzes. Code splitsen kan de eerste download verkleinen, maar als een interactie vervolgens op een extra bestand wacht, wordt die handeling niet per se sneller. Een filtercomponent pas laden bij openen bespaart werk op pagina’s waar niemand filters gebruikt; bij de eerste opening kan wel een korte vertraging ontstaan. Meet dus de volledige interactie en niet uitsluitend de omvang van de eerste JavaScript-download.
Ook de manier waarop een interface wordt bijgewerkt doet ertoe. Een zoekfilter dat bij elke toetsaanslag duizenden elementen opnieuw rendert, veroorzaakt meer werk dan een gerichte update. Debouncing kan onnodige zoekopdrachten beperken, maar een te lange wachttijd maakt de interface juist minder direct. Een knop die pas na een omvangrijke netwerkrespons feedback geeft, kan eerder een laadstatus tonen, mits die status snel zichtbaar is en de uiteindelijke handeling correct blijft. Analyseer lange taken en de betrokken interactie samen; anders bestaat het risico dat je scripts optimaliseert die veel bytes wegen maar niet de oorzaak van de trage ervaring zijn.
Cumulative Layout Shift: waarom verspringende pagina’s hinderlijk zijn
Cumulative Layout Shift (CLS) meet onverwachte verschuivingen van zichtbare elementen tijdens het laden en gebruiken van een pagina. De score houdt rekening met de grootte van het verschoven gebied en de afstand waarover elementen bewegen. Een knop die opschuift doordat er bovenaan een afbeelding verschijnt, kan ervoor zorgen dat iemand per ongeluk op een andere link klikt. CLS meet dus geen gewone beweging die bij de interactie hoort, zoals een menu dat na een klik bewust uitklapt. Het gaat vooral om wijzigingen die onverwacht gebeuren terwijl de bezoeker de pagina probeert te lezen of bedienen.
Een CLS van maximaal 0,1 geldt als goed; boven 0,25 is de score slecht. De waarden ertussen wijzen op ruimte voor verbetering. De score is cumulatief, maar wordt niet simpelweg over de volledige levensduur van een pagina opgeteld: de meting werkt met vensters van layoutverschuivingen. Verschuivingen die kort na een gebruikersactie plaatsvinden, kunnen onder voorwaarden buiten de score vallen. Dat maakt de metriek bruikbaar voor onverwachte instabiliteit, maar sluit niet uit dat een bewuste animatie alsnog verwarrend of moeilijk te bedienen is.
Een praktische manier om het probleem te herkennen is de pagina observeren tijdens laden én tijdens interactie. Let op afbeeldingen die de tekst naar beneden duwen, banners die later verschijnen en knoppen waarvan de positie verandert. De oorzaak kan op een andere plek liggen dan het element dat verschuift: een advertentie bovenaan kan bijvoorbeeld de hele inhoud eronder verplaatsen. Een CLS-score zonder zicht op de betrokken elementen vertelt daarom niet welk onderdeel aangepast moet worden. Browsertools en opnamen van echte bezoeken helpen om de volgorde van gebeurtenissen te reconstrueren.
Afbeeldingen, lettertypen en banners veroorzaken layoutverschuivingen
Afbeeldingen en video’s veroorzaken verschuivingen wanneer de browser hun ruimte niet vooraf kent. Zonder opgegeven breedte en hoogte kan de pagina eerst een klein of leeg gebied tonen en daarna ruimte reserveren zodra het bestand binnen is. Geef media daarom afmetingen op of gebruik een passende beeldverhouding, zodat de browser de benodigde ruimte al tijdens het opbouwen van de pagina kan vrijhouden. Dit blijft belangrijk bij responsieve afbeeldingen: de vorm en verhouding moeten passen bij de varianten die op verschillende schermen worden geladen.
Lettertypen zijn een tweede veelvoorkomende bron. Wanneer tekst eerst in een beschikbaar systeemlettertype verschijnt en daarna in een webfont met andere letterbreedtes, kunnen regels afbreken en elementen verschuiven. Een lettertype vooraf laden kan helpen als het daadwerkelijk nodig is voor het eerste scherm, maar te veel vooraf geladen fonts concurreren met andere belangrijke bestanden. Een alternatief is een vervangend lettertype kiezen met vergelijkbare metriek, zodat de overgang minder verschil in regelbreedte veroorzaakt. De afweging zit tussen snelle tekstweergave, merkuitstraling en een stabiele tekstindeling.
Ook advertenties, cookiemeldingen, aanbevelingen en ingesloten video’s kunnen onverwacht ruimte innemen. Reserveer waar mogelijk een vaste of minimaal voorspelbare ruimte, ook als de inhoud nog niet is geladen. Een advertentieplek die soms leeg blijft en soms groot wordt, vraagt om een ontwerp dat beide situaties aankan. Een cookiebanner die pas na een vertraagde toestemmingcontrole boven de inhoud verschijnt, kan de hele pagina verplaatsen; een vaste overlay voorkomt dat soms, maar kan inhoud bedekken en de bediening op mobiel bemoeilijken. De oplossing moet dus zowel de layout als de toegankelijkheid en bruikbaarheid respecteren.
Core Web Vitals rapporten vergelijken met tests en paginagedrag
Veldgegevens en labmetingen beantwoorden verschillende vragen. Veldgegevens komen van echte bezoeken en laten zien wat bezoekers onder uiteenlopende omstandigheden ervaren. Google Search Console groepeert URL’s met vergelijkbare problemen en rapporteert waarden op basis van Chrome-gebruikersgegevens wanneer voldoende meetmateriaal beschikbaar is. Een URL zonder veldgegevens is niet automatisch snel of traag: er kan simpelweg te weinig verkeer zijn. Ook kunnen de gegevens achterlopen op een recente wijziging, omdat ze over een periode worden verzameld.
Een labtest, bijvoorbeeld met Lighthouse, voert een gecontroleerde simulatie uit. Dat is handig om veranderingen te vergelijken en mogelijke oorzaken op te sporen, maar het resultaat is geen vervanging voor veldgegevens. Een test op een snelle ontwikkelcomputer, met een lege cache en een gekozen netwerkprofiel, kan anders uitpakken dan een bezoek op een ouder mobiel toestel met een wisselende verbinding. Een goede werkwijze gebruikt labtests om een hypothese te onderzoeken en veldgegevens om te controleren of bezoekers er daadwerkelijk baat bij hebben.
Vergelijk resultaten per apparaat, paginatype en relevante interactie. Als veel productpagina’s een slechte LCP hebben maar categoriepagina’s niet, onderzoek dan verschillen in afbeeldingen, templates of API-aanroepen. Als INP vooral op pagina’s met filters achterblijft, richt de analyse zich waarschijnlijk op die bediening in plaats van op de hele website. Bekijk bij CLS de concrete verschuivende elementen en de gebeurtenis die eraan voorafgaat. Kijk daarnaast naar technische veranderingen en campagnes: een nieuwe marketingtag of extra contentblok kan scores beïnvloeden zonder dat de kerncode is aangepast. Zo voorkom je dat één laboratoriumscore leidt tot een brede ingreep die het echte probleem niet raakt.
Welke optimalisatie je kiest hangt af van de oorzaak
Begin bij een meetbaar knelpunt en stel een concrete vraag. Is een LCP van een productpagina hoog omdat de server laat antwoordt, omdat de hoofdafbeelding te zwaar is of omdat een script de weergave uitstelt? Is een trage INP gekoppeld aan het openen van filters, het wijzigen van een variant of het toevoegen aan de winkelwagen? Verplaatst bij CLS een banner de inhoud, of veranderen tekstregels na het laden van een lettertype? Door de betrokken pagina, interactie en fase te benoemen, wordt de kans kleiner dat tijd naar een niet-relevante optimalisatie gaat.
Maak vervolgens een beperkte wijziging en vergelijk dezelfde situatie voor en na. Dat kan betekenen dat je een LCP-afbeelding eerder laat ontdekken, een script uitstelt dat niet nodig is voor het eerste scherm of afmetingen reserveert voor een embed. Controleer tegelijk op neveneffecten. Een grotere cache kan serverreacties versnellen maar verouderde informatie tonen als invalidatie niet goed geregeld is. Een afgeslankte productgalerij kan sneller laden maar belangrijke productdetails minder zichtbaar maken. Minder JavaScript helpt niet wanneer de gekozen vervanging een extra netwerkronde toevoegt voordat een bediening werkt.
Performance is daarom ook een inhoudelijke en organisatorische keuze. Een redactionele pagina met veel afbeeldingen kan snel blijven als beelden goed zijn voorbereid en ruimte krijgen; een licht ogende pagina kan traag zijn door trackingcode of een zwaar lettertype. Leg bij nieuwe functies vast wat ze toevoegen aan bestanden, scripts, externe verzoeken en dynamische content. Controleer na publicatie zowel synthetische tests als veldgegevens, en let op verschillen tussen mobiel en desktop. Veranderingen in verkeer, browsergedrag of externe diensten kunnen een eerdere verbetering later tenietdoen. De score is daarmee geen eenmalige oplevercheck, maar een meetpunt dat bij wijzigingen opnieuw betekenis krijgt.