Hoe snel moet je website zijn, en hoe meet je dat zelf? Core Web Vitals uitgelegd

Een pagina is snel genoeg als het grootste element binnen 2,5 seconde staat, de layout minder dan 0,1 verschuift en een klik binnen 200 milliseconden reactie geeft. Zo meet je dat zelf na, op je eigen site.

Een pagina is snel genoeg als het grootste element binnen 2,5 seconde in beeld staat, de layout tijdens het laden minder dan 0,1 verschuift, en een klik binnen 200 milliseconden zichtbaar reactie geeft. Dat zijn de drie Core Web Vitals, en ze worden gemeten bij je echte bezoekers, niet in een testopstelling. Nameten kan gratis en kost ongeveer tien minuten.

Core Web Vitals zijn drie meetwaarden waarmee Google de ervaring van een bezoeker uitdrukt in cijfers: laadsnelheid, stabiliteit van de layout en reactiesnelheid op invoer. Ze staan los van hoe mooi of hoe goed je site is, en juist daarom zijn ze bruikbaar: je kunt er niet over onderhandelen.

Wat zijn de drempelwaarden precies?

Twee dingen bij die tabel die vaak misgaan.

Ten eerste wordt er beoordeeld op het 75e percentiel van je bezoekers. Niet het gemiddelde. Drie van de vier bezoekers moeten binnen de grens vallen, dus de bezoeker met een oudere Android op 4G in een bedrijfshal telt mee. Dat is precies de bezoeker die bij een aannemer of installateur vaak voorkomt.

Ten tweede worden mobiel en desktop apart beoordeeld. Bijna alle sites die ik langs zie krijgen zijn op desktop in orde en op mobiel niet. Kijk dus naar het mobiele tabblad en niet naar het getal dat je het beste uitkomt.

LCP: staat het belangrijkste er snel?

LCP (largest contentful paint) is het moment waarop het grootste zichtbare element geladen is: meestal je hero-afbeelding of de grote kop erboven. Het is de beste benadering van “ik zie waar ik ben”.

De vier stukken waaruit LCP is opgebouwd zijn de tijd tot het eerste byte van de server, de tijd voordat het browsertje weet welk plaatje het moet halen, de tijd om dat plaatje binnen te halen, en de tijd om het te tekenen. Bij mkb-sites zit de schade meestal in de middelste twee: een hero-foto van 3 MB die rechtstreeks uit de camera komt, of een afbeelding die pas ontdekt wordt nadat een script is uitgevoerd.

CLS: verspringt de pagina onder je duim?

CLS (cumulative layout shift) telt hoeveel de inhoud verschuift nadat hij al zichtbaar was. Je kent het effect: je wilt op “offerte aanvragen” tikken, er valt een cookiemelding in, en je zit op iets anders.

De vier gebruikelijke oorzaken zijn afbeeldingen zonder opgegeven breedte en hoogte, banners en meldingen die bovenaan worden ingeschoven, advertenties of widgets die later plek innemen, en een webfont dat pas laadt als de tekst er al staat en dan alles opnieuw laat lopen. Alle vier zijn op te lossen door de ruimte vooraf te reserveren.

INP: reageert de pagina op wat je doet?

INP (interaction to next paint) meet hoe lang het duurt voordat je iets ziet gebeuren na een tik of klik, over alle interacties op de pagina. Het verving in 2024 de oudere meetwaarde FID, die alleen naar de eerste interactie keek en daardoor te vriendelijk was.

Een slechte INP komt vrijwel altijd door JavaScript dat de hoofdthread bezet houdt: zware sliders, chatwidgets, tagbeheerders met een stapel pixels erin, of een formulier dat bij elke toetsaanslag iets zwaars uitrekent. De browser kan maar één ding tegelijk, en zolang een script draait, gebeurt er met jouw tik niets.

Wat is het verschil tussen labdata en velddata?

Labdata komt uit een gesimuleerde test, velddata van je echte bezoekers. De drempelwaarden hierboven gelden voor velddata.

Een labtest zoals Lighthouse laadt je pagina één keer, op een vaste nagebootste telefoon met een vaste nagebootste verbinding. Dat is handig om te vinden wát er mis is, want je krijgt een lijst met oorzaken. Het is ongeschikt om te bepalen hoe je site het doet, want jouw bezoekers hebben andere toestellen, andere verbindingen en een gevulde cache.

Velddata komt bij Google uit metingen van Chrome-gebruikers die dat delen, samengevat over een rollend venster van 28 dagen. Daar zitten twee gevolgen aan. Een verbetering die je vandaag doorvoert, is pas over weken volledig terug te zien. En een site met weinig bezoek krijgt helemaal geen velddata te zien, omdat er te weinig metingen zijn.

Hoe meet je het zelf na?

Vier stappen, van grof naar fijn. Je hebt niets nodig behalve een browser.

1. PageSpeed Insights (pagespeed.web.dev). Plak je adres, kies het mobiele tabblad. Bovenaan staat de velddata als die er is, daaronder de labtest met de lijst oorzaken. Doe dit niet alleen voor je homepage: test ook de dienstenpagina en de contactpagina, want dat zijn de pagina’s waar het werk vandaan komt.
2. Search Console, het rapport Core Web Vitals. Dat groepeert al je pagina’s op basis van velddata en laat zien welke groepen niet door de drempel komen. Dit is de enige plek waar je de hele site in één keer ziet.
3. De ontwikkelaarsbalk in Chrome, tabblad Lighthouse of Performance. Draai de test in een incognitovenster en zet de invoegtoepassingen uit, anders meet je je eigen browser.
4. Meten bij je eigen bezoekers. Wil je de echte cijfers van jouw publiek, dan neem je de web-vitals-bibliotheek op in je site en stuur je de waarden naar je eigen statistieken. Dat werkt ook voor sites met te weinig bezoek voor de velddata van Google.

Die laatste stap doen wij standaard, en op deze site zie je hem letterlijk: onderaan elke pagina staat wat deze pagina zojuist in jouw browser heeft gedaan aan laadtijd, verschuiving en hoeveelheid JavaScript. Een cijfer dat op de pagina zelf staat, dwingt je om het bij te houden.

Wat maakt een mkb-site in de praktijk traag?

Bijna altijd dezelfde vier dingen, in deze volgorde van omvang.

Afbeeldingen. Foto’s die rechtstreeks uit de camera van de projectleider komen, in volle resolutie, in een formaat uit 1995. De aanpak: schalen naar de grootte waarop ze getoond worden, opslaan als WebP of AVIF, width en height meegeven zodat de ruimte gereserveerd wordt, en alles onder de vouw pas laden als het in beeld komt. Alleen de hero-afbeelding niet, die moet juist meteen.

Scripts van derden. De cookiemelding, de chatwidget, de tagbeheerder, de reviewbalk, de kaart van Google. Elk stuk voelt onschuldig en samen leggen ze de pagina plat. Maak één keer een lijstje van wat er op je site geladen wordt en wie er verantwoordelijk is voor elk stuk. Bij drie van de vier sites staan er dingen op die niemand meer gebruikt.

Lettertypes. Twee lettertypes in vier diktes, opgehaald bij een externe dienst, geven zowel vertraging als verspringing. Zet ze op je eigen server, laad alleen de diktes die je gebruikt, en geef de browser opdracht de tekst meteen te tonen in een reservelettertype.

De server. De tijd tot het eerste byte is geen Core Web Vital, maar wel het startpunt van alles wat erna komt. Kom je daar boven de 800 milliseconden, dan levert sleutelen aan de pagina zelf weinig meer op, want het probleem zit bij je hosting. Gedeelde hosting met een zware stapel losse uitbreidingen is de gebruikelijke oorzaak. De afweging wanneer dat nog te repareren is en wanneer niet, staat in WordPress of een site op maat.

Telt snelheid mee voor je positie in Google?

Ja, als een van de signalen, en het is een kleiner signaal dan mensen hopen. Van slecht naar goed schuif je zelden voorbij een pagina die inhoudelijk sterker is.

Waar snelheid wel hard doorwerkt is in gedrag. Mensen die op een bouwplaats met één streepje bereik je pagina openen, wachten niet. En bij AI-antwoorden speelt hetzelfde mee vanaf de andere kant: de crawlers van AI-bedrijven halen je pagina op met een tijdslimiet en voeren meestal geen JavaScript uit, dus een zware pagina die pas na het laden van scripts inhoud toont, levert een lege lezing op. Dat staat verder uitgewerkt in genoemd worden in AI-antwoorden.

En snelheid alleen is nooit het hele verhaal. Een pagina die in 1,2 seconde staat maar niet duidelijk maakt wat je doet en wat het kost, levert nog steeds niets op. Dat probleem staat beschreven in bezoekers maar geen aanvragen.

Meet vanavond je eigen dienstenpagina in PageSpeed Insights op het mobiele tabblad, schrijf de drie getallen op met de datum erbij, en herhaal het over een maand. Weet je niet wat je met de uitkomst aan moet, dan kijken we mee: op websites staat hoe we dat doen.