De test zelf is het probleem niet. URL invullen, op analyseren klikken, klaar. Binnen een minuut staart een getal je aan, meestal oranje. Het probleem begint daarna: wat betekent dat getal, waarom zegt de ene tool 62 en de andere 89, en moet je nu je afbeeldingen verkleinen, een plugin verwijderen of van host wisselen? Daar gaat dit artikel over. Niet het zoveelste lijstje met vijf tools, maar uitleg over wat de cijfers betekenen en wat je ermee doet.
Website snelheid testen in drie stappen
Je test de snelheid van je website door drie metingen te combineren: één voor het oordeel van Google, één voor de diagnose en één als second opinion. Zo doe je het in een kwartier:
- Begin bij PageSpeed Insights en kijk éérst naar het blok “Ontdek wat je echte gebruikers ervaren”, niet naar de score eronder. Dit zijn de velddata: metingen van echte Chrome-bezoekers van jouw site. Staat daar “onvoldoende gegevens”, dan heeft je site te weinig bezoek voor velddata en val je terug op de labtest.
- Draai daarna een test bij GTmetrix of WebPageTest en bekijk de waterval: de lijst van alles wat je pagina laadt, in volgorde. Hier zie je wélk bestand de boel ophoudt. Let vooral op de eerste regel (dat is je server) en op de grootste blokken (meestal afbeeldingen en scripts).
- Herhaal de meting op een ander moment van de dag. Eén meting is een momentopname; servers hebben drukke en rustige uren. Twee metingen die allebei traag zijn, zijn een patroon.
Test altijd de mobiele variant. Google beoordeelt je site op de mobiele ervaring, en daar vallen de resultaten vrijwel altijd lager uit.
De drie cijfers die er echt toe doen
De Core Web Vitals zijn de drie metingen waarop Google de gebruikerservaring van je site beoordeelt. Ze hebben elk een harde drempel, gemeten op het 75e percentiel: driekwart van je bezoekers moet de drempel halen.1
| Metric | Meet | Goed |
|---|---|---|
| LCP (Largest Contentful Paint) | Wanneer het grootste element zichtbaar is | ≤ 2,5 seconden |
| INP (Interaction to Next Paint) | Hoe snel de pagina reageert op klikken en typen | ≤ 200 milliseconden |
| CLS (Cumulative Layout Shift) | Hoeveel de layout verspringt tijdens het laden | ≤ 0,1 |
Twee dingen die de meeste uitleg overslaan. Ten eerste: INP is sinds 2024 de officiële interactiemetric en verving toen FID; kom je ergens nog advies over FID tegen, dan lees je een verouderd artikel.1 Ten tweede: dat 75e percentiel is belangrijker dan het lijkt. Je site kan op jouw glasvezel razendsnel voelen terwijl een kwart van je bezoekers op een oude telefoon zit te wachten. De drempel gaat over hen, niet over jou.
Lab en veld: waarom PageSpeed twee verhalen vertelt
PageSpeed Insights toont twee soorten data die elkaar gerust kunnen tegenspreken. De velddata bovenin komt uit het Chrome UX Report (CrUX): echte metingen van echte bezoekers, verzameld over de afgelopen 28 dagen. De score onderin komt uit Lighthouse: een labtest op één gesimuleerd apparaat met één gesimuleerde verbinding.5
Voor je positie in Google telt het veld, voor je diagnose het lab. De labtest is reproduceerbaar en wijst aan wát er traag is; de velddata vertelt of het in de praktijk ook een probleem ís. En dat 28-dagenvenster verklaart een klassieke frustratie: je lost iets op, test opnieuw, en de velddata staat nog steeds op oranje. Dat klopt. De meting bevat nog vier weken geschiedenis en schuift maar langzaam op. Beoordeel je fix dus in het lab en heb geduld met het veld.
Die score van 90 is geen snelheid
De Lighthouse-score is geen laadtijd maar een gewogen rapportcijfer over vijf labmetingen. De verdeling is openbaar en verrast de meeste site-eigenaren: interactiviteit (Total Blocking Time) weegt met 30% het zwaarst, terwijl de twee metrics die je het eerst ziet (First Contentful Paint en Speed Index) samen maar 20% uitmaken.3
| Metric | Meet | Weging |
|---|---|---|
| Total Blocking Time | Hoe lang de pagina bevroren is door scripts | 30% |
| Largest Contentful Paint | Wanneer het grootste element zichtbaar is | 25% |
| Cumulative Layout Shift | Hoeveel de layout verspringt | 25% |
| First Contentful Paint | Wanneer het eerste element zichtbaar is | 10% |
| Speed Index | Hoe snel de pagina visueel vult | 10% |
De schaal is bovendien geen rechte lijn. Google kalibreert de score op data van miljoenen websites uit HTTP Archive: een 90 betekent dat je bij de snelste 8% van het web hoort, een 50 bij de snelste 25%.3 Van 50 naar 70 is dus een veel kleinere prestatie dan van 85 naar 95. Wie “minimaal een 90” als doel krijgt opgelegd, mag dat cijfer met deze context best ter discussie stellen.
”Ik heb meer omzet zien verdampen aan het jagen op een groene 100 dan aan trage websites zelf. Die score is een rapportcijfer voor een gesimuleerde telefoon, geen kassa. Staat je LCP onder de 2,5 seconden en reageert je site direct, ga dan iets nuttigs doen. Je bezoekers zien dat getal nooit.”
Welke tool voor welke vraag
Elke tool beantwoordt een andere vraag. Dit is de keuzehulp die de meeste toollijstjes overslaan:
| Jouw vraag | Gebruik | Waarom |
|---|---|---|
| “Wat vindt Google van mijn site?” | PageSpeed Insights (velddata) | Enige tool met de CrUX-data waar Google op rankt |
| “Wélk bestand maakt mijn site traag?” | GTmetrix of WebPageTest (waterval) | Toont elk geladen bestand met tijd en grootte |
| “Is mijn server of mijn site het probleem?” | Elke tool, kijk naar TTFB | Eerste byte boven 800 ms wijst naar de server |
| “Hoe snel is mijn site vanuit het buitenland?” | WebPageTest (testlocatie kiezen) | Test vanaf servers wereldwijd |
| “Is mijn site nu offline of traag?” | Uptrends of Pingdom | Losse checks en doorlopende monitoring |
Voor een Nederlandse site met Nederlands publiek: kies bij GTmetrix of WebPageTest een testlocatie in of dicht bij Nederland (Londen of Frankfurt). Een test vanuit Canada geeft een vertekend beeld, want elke duizend kilometer kost tijd.
Wanneer je hosting de schuldige is
Eén regel in de testuitslag verraadt je hostingkwaliteit: de Time to First Byte. Dat is de tijd tussen je aanvraag en de allereerste reactie van de server, inclusief de DNS-lookup (hoe dat werkt lees je in onze DNS-uitleg). Google hanteert als richtlijn: onder de 800 milliseconden is goed, boven de 1,8 seconden is slecht.2
De vuistregel voor de diagnose: is je TTFB hoog, dan ligt het probleem bij je server en schiet optimaliseren van afbeeldingen niet op. Denk aan een overbelast gedeeld pakket, geen server-caching of een datacenter ver van je bezoekers. Is je TTFB laag maar je LCP traag, dan is je site zelf aan zet. Meestal zijn het de afbeeldingen, soms een thema dat een vrachtlading scripts meesleept.
In dat eerste geval heb je drie routes. Een beter pakket bij je huidige host, een snellere host (in onze vergelijker zie je de uptime- en supportscores per aanbieder naast elkaar), of een VPS als je site uit gedeelde hosting groeit. Draai je op WordPress, kijk dan naar hosts met LiteSpeed of serverside caching in onze categorie WordPress-hosting; voor een webshop, waar elke tiende seconde conversie kost, is webshop-hosting het startpunt. Overstappen is minder werk dan het klinkt: zo verhuis je zonder downtime.
Hoe erg is het als je zakt? De cijfers
Zakken voor de Core Web Vitals is eerder regel dan uitzondering. Volgens de Web Almanac 2025 van HTTP Archive haalt 48% van de websites wereldwijd goede Core Web Vitals op mobiel en 56% op desktop.4 Ruim de helft van het mobiele web zakt dus. Het gat zit vrijwel altijd op dezelfde plek: op mobiel haalt 62% een goede LCP, tegenover 77% voor INP en 81% voor CLS. Laadsnelheid van het grootste element is de bottleneck van het web, niet interactiviteit.
Er zit wel beweging in. Het mobiele slagingspercentage klom van 36% in 2023 via 44% in 2024 naar 48% in 2025.4 Het web wordt elk jaar sneller, en dat betekent ook: stilstaan is relatief achteruitgaan. De concurrent die dit jaar zijn hosting verbeterde, schoof een stukje op in die statistiek.
Wil je weten wat er aan de serverkant van de Nederlandse markt gebeurt, van uptime-beloftes tot datacenterlocaties: die cijfers houden we bij op onze hostingmarkt-datapagina. En begin je net en wil je eerst snappen waar hosting eigenlijk uit bestaat, start dan bij wat is webhosting.
