Websitesnelheid goed meten: zo pak je het aan

Wil je de snelheid van je website goed meten, combineer dan twee soorten gegevens: labtests, die je pagina onder gecontroleerde omstandigheden laden en je helpen bij het debuggen, en velddata, die laat zien hoe snel je site echt is voor echte bezoekers. Gebruik voor en na elke wijziging dezelfde tools, pagina's en instellingen, herhaal elke test meerdere keren en beoordeel het resultaat op medianen en gegevens van echte gebruikers, niet op één losse score. Deze gids legt uit welke tool je waarvoor gebruikt en hoe je een voor-en-navergelijking maakt waarop je kunt vertrouwen.

Labdata versus velddata

Bijna alle verwarring over websitesnelheid komt voort uit het door elkaar halen van deze twee.

Labdata komt uit een test op één apparaat, met één netwerkprofiel en vanaf één locatie. Lighthouse is het bekendste voorbeeld. Het draait achter de PageSpeed Insights-gegevens van Google, die corewebvitals.page gebruikt, en het zit ingebouwd in Chrome DevTools. Labtests zijn herhaalbaar en geven gedetailleerde diagnoses, dus ze zijn ideaal om oorzaken te vinden en te controleren of een oplossing werkt. Maar het blijft een simulatie: één bezoek, met een bepaald throttlingprofiel, vanaf de plek waar de test draait.

Velddata, ook wel real-user monitoring (RUM) genoemd, komt van echte bezoekers op hun eigen telefoons, laptops en netwerken. Google verzamelt die gegevens van Chrome-gebruikers in het Chrome UX Report (CrUX). Je ziet ze in Search Console, en tools zoals corewebvitals.page tonen ze voor elke URL. Velddata is wat Google gebruikt voor de beoordeling van paginagebruik, en het weerspiegelt de werkelijkheid, inclusief trage apparaten en bezoekers ver weg. Het nadeel is de snelheid van de feedback: CrUX rapporteert over een doorlopende periode van 28 dagen, dus een wijziging die je vandaag doorvoert, is pas na weken volledig zichtbaar.

Gebruik labdata om aan de slag te gaan en velddata om te beoordelen of het werk iets heeft opgeleverd.

De juiste tool voor elke taak

Je hebt geen grote gereedschapskist nodig. Vier tools dekken bijna alles.

corewebvitals.page

corewebvitals.page toont beide soorten gegevens voor mobiel en desktop, op basis van de PageSpeed Insights-gegevens van Google: velddata uit CrUX over de afgelopen 28 dagen, als je site genoeg verkeer heeft, en een Lighthouse-labrun. Lees eerst de velddata. De performancescore van 0 tot 100 hoort alleen bij het labgedeelte en is niet wat Google voor de ranking gebruikt.

Search Console

Het Core Web Vitals-rapport in Google Search Console groepeert je URL's op status (goed, verbetering nodig, slecht) op basis van velddata. Het is de beste plek om te zien welke paginatemplates problemen hebben over de hele site, in plaats van URL's één voor één te testen.

Chrome DevTools

De panelen Performance en Netwerk laten precies zien wat er tijdens het laden gebeurt: welk verzoek het renderen blokkeert, welk script de main thread bezet en hoe lang de server nodig heeft om te antwoorden. Het Lighthouse-paneel voert hetzelfde soort labtest lokaal uit. Gebruik een incognitovenster, zodat browserextensies de resultaten niet vertekenen.

Controles via de commandline

Voor de responstijd van de server geeft curl je een zuiver, herhaalbaar getal, zonder overhead van een browser:

for i in 1 2 3 4 5; do
  curl -o /dev/null -s -w "%{time_starttransfer}\n" https://example.com/
done

Dit toont de time to first byte voor vijf opeenvolgende verzoeken. Vooral handig om wijzigingen aan caching en server te controleren. De gids over TTFB verlagen legt uit hoe je dat getal verder uitsplitst.

Naar welke meetwaarden je kijkt

Concentreer je op een paar meetwaarden die beschrijven wat bezoekers ervaren:

• Largest Contentful Paint (LCP): wanneer de hoofdinhoud verschijnt. Goed is 2,5 s of minder.
• Interaction to Next Paint (INP): hoe snel de pagina reageert op klikken en tikken. Goed is 200 ms of minder. Alleen meetbaar in velddata.
• Cumulative Layout Shift (CLS): hoeveel de lay-out verspringt. Goed is 0,1 of minder.
• Time to First Byte (TTFB): hoe snel de server begint te antwoorden. web.dev raadt 0,8 s of minder aan.

Google beoordeelt de drie Core Web Vitals (Engelstalig) op het 75e percentiel van de laadbeurten, apart voor mobiel en desktop. Dat betekent dat drie van de vier bezoeken de drempel moeten halen. De gids over Core Web Vitals behandelt wat elke meetwaarde beïnvloedt en hoe je hem verbetert.

De totale paginagrootte en de tijd tot "volledig geladen" zijn minder nuttig dan ze lijken. Een pagina kan laat klaar zijn met laden door een chatwidget die niemand opvalt, terwijl een trage hero-afbeelding die iedereen opvalt nauwelijks invloed heeft op de totale laadtijd.

Waarom je resultaten alle kanten op springen

Voer je dezelfde labtest drie keer uit en krijg je drie verschillende scores, dan is er niets kapot. Veelvoorkomende redenen:

• Koude versus warme cache. Het eerste verzoek na een deploy of purge is vaak veel trager dan de volgende, op je server en op elk CDN.
• Serverbelasting. Een test op een druk moment concurreert met echte bezoekers.
• Scripts van derden. Advertenties, tagmanagers en chatwidgets laden elke keer andere inhoud.
• Testlocatie. Labtests op basis van de PageSpeed Insights-gegevens van Google, ook die op corewebvitals.page, draaien vanuit een datacenter van Google. Staat je server op een ander continent, dan meet de test die afstand.
• De testcomputer. Lighthouse in DevTools hangt af van de CPU van je eigen computer en van alles wat daar verder op draait.

Een voor-en-navergelijking waarop je kunt vertrouwen

Verander je iets, zoals je caching, een nieuw thema of een CDN, volg dan een vaste routine, zodat de vergelijking eerlijk is.

1. Kies representatieve pagina's. Neem er één van elk belangrijk template: homepage, categorie- of overzichtspagina, product- of artikelpagina. Neem ook je meest bezochte landingspagina mee.
2. Leg de omstandigheden vast. Dezelfde tool, hetzelfde apparaatprofiel (mobiel en desktop apart), dezelfde testlocatie en zo mogelijk hetzelfde tijdstip van de dag.
3. Eerst opwarmen, dan meten. Laad elke pagina één keer en gooi dat resultaat weg, tenzij je juist de prestaties bij een eerste bezoek wilt meten. Voer daarna minstens vijf tests per pagina uit.
4. Gebruik de mediaan. Neem de middelste waarde van je runs, niet de beste. Noteer bij labruns LCP, CLS, TTFB en Total Blocking Time.
5. Verander één ding tegelijk. Wissel je hosting en thema in één keer, dan weet je niet wat er hielp.
6. Herhaal na de wijziging precies dezelfde routine. Vergelijk de medianen per pagina.
7. Bevestig met velddata. Volg in de weken daarna de velddata op corewebvitals.page en in Search Console. Winst in het lab die echte gebruikers niet merken, is geen echte winst.

Gebruik je een CDN of edge-cache, controleer dan of de geteste pagina tijdens de runs "na" echt uit de cache kwam. Anders meet je je origin, niet de wijziging.

Zo helpt fast.site je

fast.site zit vóór je bestaande hosting als edge-netwerk met caching, beeldoptimalisatie en beveiliging. Je houdt je host en laat de nameservers van je domein naar fast.site wijzen; na verificatie worden verzoeken via de edge geleverd.

Voor het meten zijn twee dingen belangrijk. Ten eerste bevat elk antwoord headers die vertellen wat er gebeurde: fs-cache toont HIT, MISS of BYPASS, en fs-cache-age en fs-cache-hits laten zien hoe lang en hoe vaak de gecachete kopie is gebruikt. Zo bevestig je eenvoudig dat je test "na" echt uit de cache kwam. Het artikel over de cache controleren laat zien hoe.

Ten tweede rapporteren de analytics in het dashboard verzoeken, cache hit ratio, bandbreedte vanaf de edge versus de origin, TTFB en foutpercentages voor je eigen verkeer. Samen met de velddata op corewebvitals.page krijg je zo een voor-en-nabeeld op basis van je echte bezoekers in plaats van één losse testrun.

De beste manier om het effect te beoordelen, is het met de routine hierboven op je eigen site te meten. Dat kan bijvoorbeeld tijdens een gratis proefperiode van 7 dagen. Abonnementen en inbegrepen verkeer staan op de prijspagina.

Veelgestelde vragen

Waarom is mijn PageSpeed-score elke keer anders?

De performancescore komt uit één labrun, en die wordt beïnvloed door serverbelasting, de staat van de cache, scripts van derden en schommelingen in het netwerk. Kleine verschillen tussen runs zijn normaal. Voer meerdere tests uit, gebruik de mediaan en vertrouw voor het echte beeld op het gedeelte met velddata.

Is een PageSpeed-score van 100 nodig?

Nee. De score is een samenvatting van een labtest en wordt niet als rankingsignaal gebruikt. Waar het om gaat, is of echte bezoekers goede Core Web Vitals krijgen, en dat zie je in de velddata. Jagen op de laatste paar punten kost vaak veel moeite zonder merkbaar verschil.

Waarom zijn er geen velddata voor mijn site?

CrUX rapporteert alleen gegevens als een URL of origin in de afgelopen 28 dagen genoeg bezoeken van Chrome-gebruikers heeft gehad. Kleinere sites of nieuwe pagina's halen die drempel vaak niet. Vertrouw in dat geval op labtests plus je eigen monitoring, tot er genoeg gegevens zijn.

Hoe lang duurt het voordat verbeteringen in Search Console zichtbaar zijn?

Velddata wordt verzameld over een doorlopende periode van 28 dagen, dus een verbetering wordt geleidelijk zichtbaar en pas na ongeveer vier weken volledig. Search Console kan extra tijd nodig hebben om gegroepeerde URL's opnieuw te valideren. Labtests tonen het effect meteen, en daarom gebruik je die om een oplossing eerst te controleren.

Moet ik mobiel of desktop testen?

Allebei, en apart. Google beoordeelt ze apart, en mobiele resultaten zijn meestal slechter door tragere CPU's en netwerken. Heb je maar tijd voor één, begin dan met mobiel.