Snelheid is de enige SEO-factor waar je klanten ook iets van merken. Een bezoeker die drie seconden naar een leeg scherm kijkt, komt niet terug om te klagen: hij drukt op terug en kiest het volgende resultaat. Google meet dat gedrag en heeft er sinds 2021 een officiële naam voor: de Core Web Vitals.
Die vitals zijn geen abstracte cijfers. Ze meten drie dingen die een mens daadwerkelijk ervaart: hoe lang het duurt voordat er iets staat, of de pagina onder je vingers wegspringt, en of de pagina reageert als je erop tikt. Dit artikel legt ze uit, samen met de totale prestatiescore en de serverkoppen die eronder liggen. Het zijn de controles die je in een SEO-rapport terugvindt onder “Snelheid”.
LCP: hoe lang duurt het voordat er iets staat
Largest Contentful Paint meet wanneer het grootste zichtbare element in beeld verschijnt. In de praktijk is dat je hero-afbeelding of je grote kop. Het is de beste benadering van het moment waarop een bezoeker denkt: de pagina is er.
Google noemt onder de 2,5 seconde goed, tussen 2,5 en 4 seconde matig en boven de 4 seconde slecht. Dat wordt gemeten op mobiel, op een verbinding die trager is dan die van jou op kantoor.
Er zijn drie gebruikelijke oorzaken. De eerste is een te zware hero-afbeelding: een foto van 3 MB die op 1200 pixels breed wordt getoond. De tweede is een trage server: als de eerste byte al na 800 milliseconden komt, ben je een derde van je budget kwijt voordat de browser iets kan doen. De derde is CSS die het tekenen blokkeert, vaak een lettertype of een stylesheet van een externe partij.
CLS: springt de pagina onder je vingers weg
Cumulative Layout Shift meet hoeveel de inhoud verschuift terwijl de pagina laadt. Iedereen kent het: je wilt op een link tikken, er laadt nog een banner boven, en je tikt op iets heel anders. Onder de 0,1 is goed, boven de 0,25 is slecht.
De oorzaak is bijna altijd hetzelfde: elementen die ruimte innemen zonder dat die ruimte van tevoren gereserveerd was. Afbeeldingen zonder width en height, advertenties, cookiemeldingen die van boven inschuiven, en webfonts die na het laden een andere regelhoogte krijgen dan het tijdelijke lettertype.
Het goede nieuws is dat dit de goedkoopste van de drie is om op te lossen. Zet breedte en hoogte op je afbeeldingen en een groot deel van het probleem verdwijnt. Meer daarover staat in het artikel over alt-teksten en snelle afbeeldingen.
TBT en INP: reageert de pagina
Total Blocking Time meet hoe lang de pagina tikken en klikken negeert omdat JavaScript de hoofdthread bezet houdt. Het is de laboratoriumversie van Interaction to Next Paint, de responsiviteitsmaat waar Google sinds 2024 daadwerkelijk op meet.
Onder de 200 milliseconden is goed, boven de 600 is slecht. De oorzaak is zelden je eigen code: het zijn meestal de scripts van derden. Een chatwidget, twee trackingpixels, een cookiebanner en een reviewsysteem samen vragen al snel meer rekentijd dan de pagina zelf.
Het is dan ook de eerste plek om te snoeien. Elke externe widget kost snelheid, en de vraag is per stuk of hij dat waard is.
De totale prestatiescore
Lighthouse, de motor achter Google PageSpeed Insights, telt de laadmetingen op tot één cijfer van 0 tot 100. Boven de 90 is goed, 50 tot 89 kan beter, onder de 50 is slecht. Wij nemen die score over zoals Google hem meet, op mobiel.
Twee dingen om te weten. Ten eerste schommelt die score: twee metingen achter elkaar kunnen vijf punten verschillen, omdat er op een gedeelde server wordt gemeten. Kijk naar de richting, niet naar het laatste cijfer achter de komma.
Ten tweede is dit een labmeting: één keer laden, op een gesimuleerd toestel. Google gebruikt voor zijn ranking bij voorkeur veldgegevens, dus wat echte bezoekers in Chrome hebben meegemaakt. Heb je genoeg verkeer, dan zie je die in Search Console onder Core Web Vitals staan. Dat is de maat die telt; de labmeting is de maat waarmee je kunt sleutelen zonder een maand te wachten.
Compressie en wat je server meestuurt
Onder de vitals ligt iets simpelers: de manier waarop je server de bestanden verstuurt. Tekst, en dat is HTML, CSS en JavaScript, hoort gecomprimeerd te worden met gzip of Brotli. Dat scheelt in de praktijk ongeveer zeventig procent aan bytes en het is meestal één regel in de serverconfiguratie of één vinkje bij je hoster.
Ons rapport meldt daarnaast twee dingen die geen punten kosten maar wel iets zeggen. De tijd tot de eerste byte laat zien hoe lang je server nodig heeft voordat hij begint te antwoorden; boven de 600 milliseconden ligt het probleem eerder bij je hosting of je database dan bij je pagina. En de X-Powered-By-kop verraadt welk PHP-versienummer je draait, wat niemand hoeft te weten die niet al ingelogd is.
Wat je vandaag kunt doen
- Meet je belangrijkste pagina op PageSpeed Insights en kijk alleen naar het mobiele tabblad.
- Zoek de grootste afbeelding op die pagina op en kijk hoeveel kilobyte hij weegt. Boven de 300 kB is er bijna altijd winst te halen.
- Tel de externe scripts op je site: chat, statistieken, reviews, advertenties. Schrap er één die niemand mist.
- Controleer bij je hoster of compressie aanstaat.
- Kijk in Search Console onder Core Web Vitals wat echte bezoekers meemaken, als je site genoeg verkeer heeft.
Wil je weten hoe jouw pagina er op deze punten voor staat, zonder er zelf in de broncode voor te duiken? Doe de gratis SEO-check: je ziet binnen enkele seconden je score en wat er per onderdeel gemeten is.
