Wat zijn Core Web Vitals? LCP, INP en CLS uitgelegd

Largest Contentful Paint (LCP) meet hoelang het duurt voordat het grootste zichtbare element (meestal een afbeelding of kop) in beeld staat. Interaction to Next Paint (INP) meet hoe snel de pagina reageert op klikken, taps en toetsaanslagen. Cumulative Layout Shift (CLS) meet hoeveel de layout verschuift tijdens het laden, bijvoorbeeld doordat een banner de tekst naar beneden duwt.

De grenswaarden komen uit de officiële documentatie van Google op web.dev. Ze gelden per pagina, niet per site: uw homepage kan goed scoren terwijl een productpagina zakt. Een site die op kantoor soepel voelt, kan op een gemiddelde telefoon via 4G alsnog de drempel missen.

Trage pagina's kosten bezoekers. Elke seconde extra laadtijd verhoogt het percentage mensen dat afhaakt voordat de pagina in beeld staat. Google gebruikt de Core Web Vitals daarnaast als ranking-signaal: bij vergelijkbare inhoud wint de snellere pagina. Voor webshops telt het dubbel, omdat een haperend bestelproces direct omzet raakt.

De metrics zijn bewust gekozen op wat een bezoeker echt merkt: hoe snel zie ik iets, hoe snel reageert het, en blijft het beeld stil staan. Een server die snel antwoordt maar een pagina die daarna seconden aan scripts uitvoert, scoort terecht slecht. Het gaat dus niet om een abstract rapportcijfer, maar om het gevoel van de pagina in de hand van de gebruiker.

Er zijn twee soorten metingen. Velddata komt van echte bezoekers (via het Chrome User Experience Report) en bepaalt hoe Google uw pagina beoordeelt. Lab-data komt uit een gesimuleerde test, zoals een scan of Lighthouse-run, en is direct beschikbaar en reproduceerbaar. Velddata is het eindoordeel; lab-data is het gereedschap om problemen te vinden en fixes te controleren.

De WebYes-scan meet lab-waarden op de gescande pagina's (maximaal zes per scan) en rekent ze mee in de pijler snelheid. Wil u weten hoe u die meting zelf uitvoert en interpreteert, lees dan ook website snelheid testen. Voor een snelle externe check kunt u daarnaast PageSpeed Insights gebruiken; die toont vaak zowel lab- als velddata wanneer er genoeg verkeer is.

Een hoge LCP komt meestal door te grote afbeeldingen, trage serverrespons of render-blokkerende scripts en stylesheets. Een hoge INP wijst vrijwel altijd op te veel JavaScript dat de hoofdthread bezet houdt, vaak door tag managers, chatwidgets en trackingscripts. CLS-problemen ontstaan door afbeeldingen zonder vaste afmetingen, laat ingeladen advertenties of webfonts die de tekst laten verspringen.

De volgorde van aanpak is bijna altijd: eerst afbeeldingen optimaliseren (formaat, compressie, lazy loading), dan overbodige scripts schrappen of uitstellen, en als laatste de serverkant versnellen met caching of een CDN. Meet na elke stap opnieuw; zonder nieuwe meting weet u niet of de fix echt werkt.

Snelheid is een van de vier pijlers van de WebYes-scan, naast mobiel, veiligheid en toegankelijkheid. Binnen die snelheidspijler kijken we onder meer naar lab-metingen die aansluiten bij de Core Web Vitals: hoe snel laadt de pagina, hoe stabiel blijft de layout, en hoe zwaar is de pagina voor de browser. De gratis scan is gelabeld als bèta en beperkt tot maximaal zes pagina's per run; een betaalde full audit mag tot vijftien pagina's sitemap-geleid meenemen.

Het keurmerk vereist een gemiddelde score van minstens 80 over de vier pijlers, én dat elke pijler afzonderlijk minstens 60 scoort. Een site met een sterke mobielscore maar een snelheidspijler onder de 60 komt dus niet door de keuring, ook al is het gemiddelde hoog. Dat is bewust: een keurmerk dat alleen op één sterke pijler leunt, zegt weinig over de ervaring van uw bezoekers. Meer over hoe u zelf meet en prioriteert, vindt u bij website snelheid testen en in de context van mobielvriendelijke websites, waar trage LCP en CLS vaak het hardst aankomen.

In herkeuringen zien we vaak dezelfde volgorde van winst. Begin bij LCP op de homepage en de belangrijkste landingspagina: hero-afbeeldingen in modern formaat (WebP of AVIF), vaste breedte/hoogte, en geen render-blokkerende CSS die de grootste paint vertraagt. Meet daarna opnieuw; een LCP die van 4,2 s naar 2,3 s zakt, voelt meteen rustiger aan en tilt de lab-score zichtbaar.

Daarna INP: inventariseer third-party scripts (chat, A/B-tools, pixel-stacks) en schakel uit wat niet essentieel is op de eerste paint. Chatwidgets die de hoofdthread blokkeren tot de bezoeker klikt, zijn een klassieke INP-boete. Pas daarna fine-tuning toe: code-splitting, idle callbacks, en minder werk in event handlers. CLS komt vaak als laatste: reserveer ruimte voor banners en cookie-balken, zodat content niet verspringt wanneer consent-UI verschijnt.

Documenteer elke fix met een voor/na-labmeting op dezelfde URL. Zonder die discipline optimaliseert u in het wilde weg en weet u niet welke wijziging de pijlerscore heeft gered. De WebYes-tijdlijn op een betaald profiel helpt daarbij: u ziet wanneer een full audit opnieuw is gedraaid en of de snelheidspijler omhoog of omlaag ging.

Core Web Vitals zeggen niets over inhoudelijke kwaliteit, toegankelijkheid of beveiliging. Een snelle pagina kan alsnog falen op contrast, ontbrekende alt-teksten of ontbrekende security headers. Daarom scoort WebYes vier pijlers apart: snelheid alleen is nooit genoeg voor het keurmerk.

Ze meten ook geen conversiepaden end-to-end. Een checkout die lab-technisch goed scoort maar drie verwarrende stappen heeft, kan alsnog afhaken. Gebruik vitals als harde ondergrens voor technische UX, niet als vervanging voor usability-tests of een menselijke WCAG-audit.