Core Web Vitals laten zien hoe snel een pagina hoofdcontent toont, hoe vlot die op interacties reageert en hoe stabiel de layout blijft. Je leest hoe LCP, INP en CLS worden gemeten, welke meetmethoden bruikbaar zijn en hoe je veelvoorkomende technische oorzaken gericht opspoort.
Wat LCP, INP en CLS precies meten
Core Web Vitals beschrijven drie onderdelen van de gebruikerservaring die met technische metingen te benaderen zijn. Largest Contentful Paint (LCP) meet wanneer het grootste zichtbare element in het viewport is weergegeven. Dat element is vaak een hero-afbeelding, een grote kop of een tekstblok. Een LCP van maximaal 2,5 seconden geldt als goed; boven 4 seconden is de score slecht. De meting begint bij het navigeren naar de pagina en zegt dus niet simpelweg hoe lang de volledige pagina nodig heeft om te laden.
Interaction to Next Paint (INP) beoordeelt de vertraging tussen gebruikersinteracties en de eerstvolgende visuele update. Denk aan klikken, tikken en toetsenbordinvoer. De waarde omvat inputvertraging, verwerking door JavaScript en de tijd tot de browser de volgende paint uitvoert. Tot 200 milliseconden geldt als goed; boven 500 milliseconden als slecht. Cumulative Layout Shift (CLS) meet onverwachte verschuivingen van zichtbare elementen tijdens de levensduur van een pagina. Een CLS tot 0,1 is goed en boven 0,25 slecht.
De drie scores vullen elkaar aan, maar zijn niet uitwisselbaar. Een pagina kan snel verschijnen en toch slecht reageren op een menuactie, of direct bruikbaar lijken terwijl tekst verspringt zodra een afbeelding laadt. Google beoordeelt velddata doorgaans op het 75e percentiel: de meeste bezoeken moeten dus binnen de goede grens vallen, niet alleen het gemiddelde.
Velddata en labdata gebruiken voor Core Web Vitals
Velddata registreert ervaringen van echte bezoekers op echte apparaten en verbindingen. De Chrome User Experience Report (CrUX) verzamelt geanonimiseerde gegevens van geschikte Chrome-gebruikers; PageSpeed Insights toont deze data waar die beschikbaar is. Real User Monitoring (RUM) kan aanvullend metingen verzamelen via eigen analyticscode. Velddata maakt verschillen zichtbaar tussen gebruikersgroepen en omstandigheden, maar is afhankelijk van voldoende verkeer, een representatieve steekproef en correcte segmentatie.
Labdata ontstaat in een gecontroleerde testomgeving. Lighthouse en de Performance-panel in Chrome DevTools laden een pagina met gesimuleerde apparaat- en netwerkcondities. Dat maakt herhaalbare vergelijking mogelijk en helpt een ontwikkelaar een specifieke oorzaak te vinden. Het is geen vervanging voor velddata: één testbezoek kan niet alle browsers, apparaten, interacties en servercondities vertegenwoordigen. INP vraagt bovendien om echte interacties; in labtests wordt vaak Total Blocking Time gebruikt als aanwijzing voor main-threadproblemen, maar die metric is niet hetzelfde als INP.
Gebruik beide soorten metingen met een verschillende vraag. Velddata beantwoordt of bezoekers op productiepagina’s problemen ervaren. Labdata helpt verklaren waarom een bepaalde pagina in een specifieke test traag is. Als de scores uiteenlopen, controleer dan eerst de testconfiguratie, het cachegedrag, de gekozen URL en het aandeel mobiel verkeer. Een labtest zonder cookies of ingelogde toestand kan bijvoorbeeld een heel andere interface laden dan bezoekers daadwerkelijk zien.
LCP analyseren met de laadketen van de grootste content
Een hoge LCP-score is een eindpuntmeting, geen diagnose. Om de oorzaak te vinden, bepaal je eerst welk element als LCP-element is geregistreerd. Chrome DevTools toont dit in de Performance-trace; Lighthouse en PageSpeed Insights geven eveneens aanwijzingen. Een grote achtergrondafbeelding, een productfoto, een koptekst of een videoposter kan de grootste content zijn. De oplossing hangt af van dat element: afbeeldingen optimaliseren helpt niet wanneer de LCP juist wordt vertraagd door een trage HTML-respons of render-blocking CSS.
De totale LCP-tijd bestaat grofweg uit server response time, resource load delay, resource load duration en element render delay. Een lange eerste fase wijst vaak op een trage server, een redirectketen of een inefficiënte cache. Bij een lange resource load delay wordt de afbeelding mogelijk laat ontdekt, bijvoorbeeld doordat die via JavaScript wordt toegevoegd of als CSS-background is ingesteld. Een lange downloadduur kan samenhangen met een te groot bestand, een verkeerd formaat of een langzaam netwerk. Render delay wijst eerder op CSS, fonts of JavaScript die het tonen van het element tegenhouden.
Controleer of de belangrijkste afbeelding vroeg in de HTML vindbaar is en niet onnodig lazy-loaded wordt. Gebruik passende afmetingen en moderne afbeeldingsformaten, maar voorkom dat alle afbeeldingen vooraf worden geladen: dat concurreert met kritieke bronnen. Een preload kan de ontdekking versnellen als de bron zeker LCP is, maar verkeerd toegepaste preloads verbruiken netwerkcapaciteit. Meet na wijzigingen op dezelfde URL en test zowel mobiel als desktop, omdat viewport en netwerk de keuze van het LCP-element kunnen veranderen.
INP-problemen opsporen in JavaScript en eventverwerking
Een trage INP ontstaat meestal rond een specifieke interactie, niet doordat de hele website voortdurend traag is. De browser moet invoer ontvangen, event handlers uitvoeren en daarna een nieuwe visuele toestand tekenen. Een zware handler kan de main thread bezet houden, waardoor de klik pas laat wordt verwerkt. Ook werk dat direct na de handler wordt ingepland kan de paint blokkeren. Grote JavaScriptbundels, synchronische berekeningen, uitgebreide DOM-mutaties en langdurige third-party scripts zijn veelvoorkomende bronnen van vertraging.
In velddata is het nuttig om interactietypen en pagina’s te vergelijken. Een filter, zoekveld of navigatiemenu kan een andere bottleneck hebben dan een knop die een eenvoudig paneel opent. De Performance-panel helpt om tijdens een reproduceerbare interactie long tasks, event callbacks en renderingwerk te inspecteren. Kijk niet alleen naar de totale duur van een handler: een taak die kort lijkt kan onderdeel zijn van een reeks taken die samen de volgende paint uitstellen. Gebruik waar passend de Long Animation Frames API of RUM-instrumentatie om problemen op productiepagina’s te herkennen.
Verbeteringen kunnen bestaan uit werk opdelen, niet-kritieke berekeningen uitstellen, event handlers versimpelen of onnodige componentupdates voorkomen. Debouncing kan bij zoekinvoer nuttig zijn, maar mag de interface niet zo lang stil houden dat de gebruiker geen feedback ziet. Een laadindicator helpt alleen als die snel kan renderen; als dezelfde main thread geblokkeerd blijft, verschijnt ook die indicator laat. Test daarom de hele interactie inclusief de zichtbare reactie, niet alleen de uitvoeringstijd van één functie.
CLS verklaren met afbeeldingen, fonts en dynamische content
Layoutverschuivingen ontstaan wanneer zichtbare elementen onverwacht van positie veranderen. Een veelvoorkomende oorzaak is media zonder gereserveerde ruimte: zodra een afbeelding of video zijn afmetingen bekendmaakt, duwt die omliggende content opzij. Geef afbeeldingen en video’s daarom expliciete width- en height-attributen of reserveer ruimte met CSS aspect-ratio. Dit voorkomt niet alleen verschuiving, maar maakt de beschikbare layout ook eerder voorspelbaar voor de browser.
Webfonts kunnen eveneens CLS veroorzaken. Een fallbackfont heeft mogelijk andere letterbreedtes dan het uiteindelijke font, waardoor regels afbreken en content verschuift wanneer de download klaar is. Font-display en een passende fallback kunnen de overgang beïnvloeden; preloaden kan helpen wanneer het font werkelijk kritiek is, maar te veel preloads concurreren met andere belangrijke bronnen. Dynamische content zoals advertenties, aanbevelingen en cookiepanelen vraagt om een gereserveerde plek of een presentatie die de bestaande layout niet onverwacht verplaatst. Elementen die boven de huidige content worden ingevoegd, zijn extra risicovol.
CLS wordt berekend uit layout-shift-events die niet volgen op een verwachte gebruikersactie. Een verschuiving na een klik kan daarom anders worden behandeld dan een onverwachte verspringing tijdens het laden. De score in een labtest kan afwijken van velddata, vooral bij pagina’s met laat ladende advertenties of interacties die tests niet uitvoeren. Gebruik de Layout Shift-regio’s in DevTools om te zien welk element bewoog en welke node de verschuiving veroorzaakte. Controleer daarna verschillende viewportbreedtes; ruimte die op desktop voldoende is, kan op mobiel alsnog te klein blijken.
Core Web Vitals vergelijken per pagina en apparaat
Een domeingemiddelde verbergt vaak waar een probleem werkelijk zit. Productdetailpagina’s, artikelpagina’s en zoekresultaten gebruiken verschillende templates, scripts en contentbronnen. Splits metingen daarom waar mogelijk uit naar paginatype, URL-groep, apparaat en relevante bezoekerscontext. Een slechte LCP op mobiel kan bijvoorbeeld voortkomen uit een zware hero-afbeelding en een beperkte netwerkverbinding, terwijl desktopbezoekers dezelfde pagina binnen de grens laden. Eén generieke optimalisatie kan dan weinig effect hebben of onnodig andere pagina’s beïnvloeden.
Let bij velddata op de steekproefgrootte en de meetperiode. CrUX werkt met een voortschrijdend venster en publiceert niet voor iedere pagina afzonderlijke gegevens. URL-data kan ontbreken of worden samengevoegd met origin-data. RUM geeft meer controle, maar vraagt om consistente URL-normalisatie en zorgvuldig gekozen dimensies. Als queryparameters voor duizenden URL-varianten zorgen, worden de gegevens versnipperd. Groepeer dan op templates of functionele routes in plaats van elke variant als aparte pagina te behandelen.
Het 75e percentiel is nuttig voor beoordeling, maar vertelt niet alles over spreiding. Bekijk waar mogelijk ook medianen en hogere percentielen, bijvoorbeeld om te zien of een kleine groep apparaten zeer slechte ervaringen heeft. Vergelijk periodes alleen als de meetmethode en segmentatie gelijk zijn. Een score kan veranderen door een campagne, een browserupdate of een gewijzigde mix van bezoekers, zonder dat de code is aangepast. Leg daarom releases en wijzigingen in externe scripts naast de meetgegevens voordat je een oorzaak aanwijst.
Chrome DevTools inzetten om de oorzaak te vinden
Een efficiënte diagnose begint met het exact reproduceren van de pagina en de handeling die traag aanvoelt. Open DevTools, schakel waar relevant netwerk- en CPU-throttling in en neem een Performance-recording op. De ingestelde simulatie is geen perfecte kopie van een echt toestel, maar maakt vergelijking tussen runs betrouwbaarder. Controleer ook of de cache uitgeschakeld of juist warm is: een koude cache laat andere knelpunten zien dan terugkerende bezoeken. Noteer de URL, viewport, browserinstellingen en handelingen zodat een tweede meting vergelijkbaar is.
De Network-panel laat zien welke resources worden opgevraagd, in welke volgorde en hoe lang ze wachten of downloaden. Een initiator kan onthullen dat een afbeelding pas na uitvoering van JavaScript wordt ontdekt. In de Performance-trace zijn main-threadtaken, rendering, layout en paint op een tijdlijn te onderzoeken. Selecteer een LCP-marker of layout shift om details over het betreffende element te bekijken. Bij interactieproblemen zoom je in op de periode tussen invoer en de eerstvolgende paint en controleer je welke scripts de thread bezet houden.
Een waterval vol requests betekent niet automatisch dat elke request geoptimaliseerd moet worden. Zoek naar afhankelijkheden: een script kan een stylesheet aanvragen, die vervolgens een font ontdekt. Het verwijderen of uitstellen van een vroeg in de keten gelegen blokkade kan meer opleveren dan het verkleinen van een afzonderlijk bestand. Herhaal de test na een wijziging en vergelijk meerdere runs, want netwerkvariatie veroorzaakt ruis. Gebruik labresultaten om hypotheses te toetsen en controleer daarna in productie of velddata dezelfde richting laat zien.
Technische oorzaken prioriteren zonder nieuwe problemen te maken
Prioriteren vraagt om meer dan de laagste score kiezen. Bepaal hoeveel pagina’s en bezoekers door het probleem worden geraakt, welke metric faalt en of de oorzaak in gedeelde code zit. Een traag script op alle templates kan meer impact hebben dan een afwijkende afbeelding op één weinig bezochte pagina. Tegelijk kan een specifieke checkout-interactie bedrijfskritiek zijn, ook als die weinig sessies vertegenwoordigt. Combineer daarom velddata met kennis van de gebruikersflow en de technische structuur van de site.
De aanpak hangt af van de bottleneck. Een serverresponsprobleem vraagt om onderzoek naar caching, backendwerk of redirects; een grote afbeelding vraagt om aandacht voor bronkeuze, afmetingen en prioriteit; een hoge INP vraagt om analyse van main-threadwerk. Verander niet tegelijk de CDN-configuratie, JavaScriptbundling en componentstructuur als je het effect afzonderlijk wilt kunnen beoordelen. Kleine, gerichte wijzigingen maken regressies beter herleidbaar. Leg per wijziging vast welke metric en welk segment de hypothese ondersteunen.
Let op optimalisaties die één metric verbeteren ten koste van een andere. Het agressief preloaden van fonts en afbeeldingen kan LCP voor één element verbeteren, maar de netwerkconcurrentie voor andere bronnen vergroten. Scripts uitstellen kan de initiële weergave versnellen, terwijl functionaliteit later beschikbaar wordt of layout na interactie verandert. Na elke wijziging controleer je daarom LCP, INP en CLS, plus de relevante paginatemplates en apparaten. Beoordeel ook echte productiegegevens na uitrol: een lokale test valideert de technische hypothese, maar niet de volledige variatie in bezoekers, content en netwerkcondities.
Veelgestelde vragen
Hebben Core Web Vitals invloed op de positie van mijn website in Google?
Ja, Core Web Vitals kunnen meewegen in Google Search, maar ze bepalen niet zelfstandig de positie van een pagina. Relevantie, kwaliteit en bruikbaarheid van de inhoud blijven belangrijke factoren. Een goede score is daarom geen garantie op een hoge ranking, net zoals een matige score niet automatisch betekent dat een pagina uit de zoekresultaten verdwijnt.
Gebruik de metingen vooral om technische hindernissen voor bezoekers weg te nemen. Combineer verbeteringen aan de gebruikerservaring met goede content en een technisch toegankelijke website; optimaliseer niet uitsluitend voor een score.
Hoe lang duurt het voordat een verbetering zichtbaar wordt in CrUX?
Een verbetering kan pas geleidelijk zichtbaar worden in CrUX, omdat de gegevens ervaringen van echte Chrome-gebruikers over een voortschrijdende periode van 28 dagen weerspiegelen. Een wijziging in de code leidt dus niet meteen tot een nieuwe veldscore: oudere bezoeken blijven tijdelijk meetellen en nieuwe bezoeken moeten voldoende gegevens opleveren.
Controleer kort na een release eerst met labtests of de technische wijziging het bedoelde effect heeft. Beoordeel het uiteindelijke effect op velddata pas nadat er genoeg nieuwe bezoeken zijn verzameld en vergelijk steeds dezelfde URL-groep en periode.
Is een Lighthouse-score van 100 nodig voor goede Core Web Vitals?
Nee, een Lighthouse-score van 100 is niet nodig om goede Core Web Vitals te behalen. Lighthouse is een labtest met een eigen samengestelde score; die score is niet hetzelfde als de veldmetingen van LCP, INP en CLS waarop de gebruikerservaring wordt beoordeeld.
Richt je op het oplossen van problemen die echte bezoekers ervaren en op het halen van de goede grenzen voor de afzonderlijke metrics. Een score najagen kan anders leiden tot onnodige aanpassingen die weinig merkbaar voordeel opleveren of andere onderdelen van de site verslechteren.
Wat kan ik doen als mijn pagina geen Core Web Vitals-velddata heeft?
Als er geen velddata voor een pagina beschikbaar is, gebruik dan labtests om de technische prestaties te onderzoeken en verzamel zo nodig eigen metingen met Real User Monitoring. Ontbrekende gegevens betekenen niet automatisch dat de pagina snel of traag is; er kan simpelweg onvoldoende geschikte gebruikersdata zijn om een betrouwbare veldscore te tonen.
Test belangrijke templates en representatieve pagina’s op mobiel en desktop. Leg daarnaast vast welke URL’s, apparaten en interacties zijn gemeten, zodat je latere resultaten eerlijk kunt vergelijken. Behandel labresultaten in deze situatie als aanwijzingen, niet als bewijs van de ervaring van alle bezoekers.
Moet ik Core Web Vitals optimaliseren als mijn pagina al veel bezoekers krijgt?
Ja, ook een populaire pagina kan baat hebben bij optimalisatie wanneer bezoekers er merkbare vertragingen of verschuivingen ervaren. Veel verkeer maakt het probleem niet kleiner, maar kan juist betekenen dat een verbetering een grote groep gebruikers bereikt. Kijk wel eerst welke metric faalt en hoeveel bezoekers of pagina’s daadwerkelijk worden geraakt.
Prioriteer ingrepen met een duidelijk gebruikersvoordeel en controleer dat ze geen nieuwe problemen veroorzaken, bijvoorbeeld door te veel bronnen vooraf te laden of functionaliteit uit te stellen die bezoekers nodig hebben. Meet na elke relevante wijziging zowel het technische effect als de ervaring op de betrokken pagina’s.
