Op deze pagina
Wat deze snelheidstest meet
Website snelheid testen doe je hier vanaf een server in Stockholm, zoals een bezoeker elders in Europa je site ophaalt. De test meet de tijd tot de eerste byte: hoe lang je server erover doet om te beginnen antwoorden. Daarna weegt hij je HTML over de lijn en uitgepakt, kijkt of de server comprimeert, telt wat de pagina laadt en weegt tot vijf van je eigen zwaarste bestanden. Hij kijkt of je eerste beeld meteen laadt, of je beelden een vaste maat hebben, hoeveel scripts van andere servers komen, op welk platform je site draait en of er een CDN voor staat. Bovenaan staat wat dat gewicht kost op trage 4G, en eronder wat je eerst oplost en wat dat ongeveer vraagt.
De rekensom achter de laadtijd
De laadtijd bovenaan is geen gok maar een rekensom in drie delen: het gewicht in bits gedeeld door 1,6 megabit per seconde, plus 0,15 seconde per verzoek, plus de servertijd. Dat zijn de waarden van traag 4G in Lighthouse, ongeveer de traagste kwart van de 4G-verbindingen. Een voorbeeld met echte getallen: een pagina met 40 kB HTML, een hero-foto van 1,4 MB en een script van 230 kB weegt samen 1.704 kB. Dat is 8,7 seconden om op te halen, plus drie verzoeken van 0,15 seconde, plus 0,3 seconde servertijd: 9,5 seconden. Zet je de foto om naar WebP op de getoonde maat, zeg 250 kB, dan valt het totaal naar 3,4 seconden. Dezelfde pagina, dezelfde foto in beeld. Hoe snel Belgische kmo-sites gemiddeld laden, per sector en per platform, lees je in ons onderzoek naar de gemiddelde laadtijd van websites in België.
De meetlat van de test, met wie de grens zet:
| Onderdeel | Goed | Let op | Traag | Grens van |
|---|---|---|---|---|
| Tijd tot de eerste byte | tot 0,8 s | 0,8 tot 1,8 s | boven 1,8 s | Google (web.dev) |
| HTML over de lijn | tot 100 kB | 100 tot 300 kB | boven 300 kB | onze vuistregel |
| Compressie | aan vanaf 10 kB HTML | uit | onze vuistregel | |
| Zwaarste beeld | tot 300 kB | tot 750 kB | boven 750 kB | onze vuistregel |
| Zwaarste script of stylesheet | tot 200 kB | tot 500 kB | boven 500 kB | onze vuistregel |
| Bestanden die het tonen ophouden | tot 2 | 3 tot 5 | meer dan 5 | onze vuistregel |
| Scripts van andere servers | tot 5 | 6 tot 11 | 12 of meer | onze vuistregel |
| Eerste beeld | laadt meteen | laadt lazy | Google (web.dev) |
Wat de test niet meet: hoe snel je pagina in een browser tekent, hoe vlot ze reageert op een tik en of er iets verspringt. Dat zijn de Core Web Vitals, en die meet Google bij echte bezoekers. De test opent geen browser en weegt geen bestanden van andere servers: die telt hij, zonder ze op te halen.
Gewicht, wachttijd en de drie drempels
Gewicht wordt wachttijd
Alleen om de bytes op te halen: gewicht in megabit gedeeld door 1,6 Mbit/s.
Villa Lidia, homepage voor 8,4 MB70,5 Mbit / 1,6 Mbit/s44 s
Mediaan mobiele pagina, 2025 2.164 kB17,7 Mbit / 1,6 Mbit/s11 s
Villa Lidia, homepage na 1,4 MB11,7 Mbit / 1,6 Mbit/s7,3 s
Wat Google bij echte bezoekers meet
Op het 75e percentiel van de bezoeken, per gsm en computer.
LCPhet grootste element staat
2,5 s4 s62% van de mobiele sites goed
INPde pagina reageert op een tik
200 ms500 ms77% goed
CLSniets verspringt
0,10,2581% goed
Alle drie goed: 48% van de mobiele sites.
De test op deze pagina meet het linkerdeel: servertijd en gewicht. Het rechterdeel komt uit Chrome bij echte bezoekers, over 28 dagen; je ziet het in PageSpeed Insights en Search Console.
Website snelheid meten met Core Web Vitals: lab en veld
Google meet snelheid met drie Core Web Vitals, telkens op het 75e percentiel van de bezoeken, apart voor gsm en computer. Dat betekent: drie op de vier bezoeken moeten de grens halen.
| Meting | Wat ze meet | Goed | Kan beter | Slecht | Mobiele sites goed in 2025 |
|---|---|---|---|---|---|
| LCP | wanneer het grootste element staat | tot 2,5 s | 2,5 tot 4 s | boven 4 s | 62% |
| INP | hoe snel de pagina reageert op een tik of klik | tot 200 ms | 200 tot 500 ms | boven 500 ms | 77% |
| CLS | hoeveel er verspringt tijdens het laden | tot 0,1 | 0,1 tot 0,25 | boven 0,25 | 81% |
| TTFB, geen Core Web Vital | wanneer de server begint te antwoorden | tot 0,8 s | 0,8 tot 1,8 s | boven 1,8 s | 44% |
Alle drie goed haalt 48 procent van de mobiele sites. Labdata en velddata meten iets anders. Velddata komt uit Chrome bij echte bezoekers, over 28 dagen: je ziet ze bovenaan in PageSpeed Insights en in het rapport Core Web Vitals van Search Console. Heeft je pagina te weinig bezoekers, dan toont PageSpeed Insights het cijfer van je hele domein, of niets. Labdata is een test met Lighthouse op een gesimuleerd middenklassetoestel op een mobiel netwerk. Lighthouse kan INP niet meten, want er tikt niemand; het toont Total Blocking Time als vervanger. De score van 0 tot 100 is een labscore: 90 of hoger is goed, onder 50 slecht. Google rankt niet op die score maar op de velddata.
Telt snelheid mee in Google? Ja, Google schrijft dat de Core Web Vitals door zijn rankingsystemen gebruikt worden. Maar relevantie gaat voor: Google toont de pagina die de vraag het best beantwoordt, ook als ze trager is, en goede scores garanderen geen toppositie. Snelheid beslist vooral tussen pagina's die even goed antwoorden. Daarom hoort deze test naast de SEO-check, niet in de plaats ervan.
Waar het gewicht zit: de vijf zwaarste oorzaken
Een mediane mobiele pagina woog in 2025 2.164 kB, verdeeld over 72 verzoeken, met 911 kB aan beelden en 646 kB aan JavaScript. Een op de tien mobiele pagina's weegt meer dan 8.337 kB. De oorzaken komen bijna altijd uit dezelfde vijf hoeken.
Beelden. Bij 76 procent van de mobiele pagina's is een beeld het grootste element, dus het beeld dat LCP bepaalt. Een foto recht uit de camera of de fotobank weegt snel meer dan je hele pagina zou mogen. WebP is bij dezelfde kwaliteit 25 tot 34 procent lichter dan JPEG, en een beeld op de maat waarop het getoond wordt, scheelt vaak meer dan het formaat. Laad dat eerste beeld nooit lazy: 16 tot 17 procent van de pagina's doet het toch, en dan wacht het grootste element op een scroll die niet komt. Geef het fetchpriority=high; dat doet maar 17 procent.
Lettertypes. Elk lettertype van een andere server is een extra verbinding voor je tekst kan verschijnen. Host ze zelf, laad alleen de gewichten die je gebruikt en zet font-display op swap.
Scripts van derden. Chatwidgets, trackers, embeds van video en kaarten, cookiebanners: elk script van een andere server is code die je niet beheert. De test telt ze; vanaf zes kijk je per script of het nog iets oplevert.
Hosting. Antwoordt de server traag, dan helpt niets anders: elke bezoeker wacht eerst. In 2025 had maar 44 procent van de mobiele sites een goede tijd tot de eerste byte. Een paginacache of een CDN dicht bij je bezoekers lost dat meestal op.
Het platform. Een pagebuilder met tientallen plugins zet veel code op elke pagina, ook waar ze niets doet. Waarom dat bij WordPress zo vaak misgaat, lees je in waarom WordPress zo traag is.
WordPress of een static export
Waar de snelheid van elk vandaan komt, en waar ze verloren gaat.
- Bij elk bezoek
- WordPressPHP bouwt de pagina uit de database, tenzij een cache ze klaarzet
- Static exportDe pagina staat al klaar als bestand
- Servertijd
- WordPressHangt af van hosting, cache en PHP-versie
- Static exportEen CDN levert het bestand vanaf een server dicht bij de bezoeker
- Wat haar vertraagt
- WordPressPlugins, een pagebuilder, zware beelden en scripts
- Static exportZware beelden en scripts die je toevoegt
- Onderhoud
- WordPressUpdates van kern, thema en plugins
- Static exportGeen database en geen plugins om bij te werken
- Zelf teksten aanpassen
- WordPressIn het dashboard
- Static exportVia de bouwer of een gekoppeld CMS
Kies WordPress als je zelf vaak publiceert en een host met paginacache neemt. Kies een static export als snelheid en weinig onderhoud zwaarder wegen dan zelf alles klikken.
Laadtijd website meten en dan: wat je per bevinding doet
De test zet de bevindingen in de volgorde waarin ze je bezoeker het meest kosten, en zegt bij de eerste wat ze ongeveer vraagt. De tijden hieronder zijn onze inschatting voor een gewone bedrijfssite, geen offerte.
| Bevinding | Wat je doet | Wat het ongeveer vraagt |
|---|---|---|
| Server traag | Paginacache aanzetten, of hosting met een CDN dichter bij je bezoekers | Vaak een dag werk, plus het verschil in hosting |
| Zwaar beeld | Verkleinen tot de getoonde maat, omzetten naar WebP of AVIF | Een paar minuten per beeld, een halve tot een hele dag voor een site |
| Geen compressie | Gzip of Brotli aanzetten bij je host of CDN | Meestal minder dan een uur |
| Eerste beeld lazy | loading=lazy weghalen, fetchpriority=high zetten | Minder dan een uur |
| Scripts die het tonen ophouden | defer of async toevoegen, of later laden | Een uur tot een halve dag |
| Veel scripts van derden | Per script beslissen of het blijft | Ongeveer een uur per script |
| Beelden zonder maat | width en height in het thema of de beelden | Een paar uur |
| Zware HTML | Inline code eruit, een lichter thema of andere bouwer | Van een paar uur tot een nieuw thema |
Hoe je elk van die stappen uitvoert, staat in website snelheid optimaliseren. Snel blijven is iets anders dan een keer snel maken: elke nieuwe foto, plugin of tracker kan het werk ongedaan maken. Dat is waarom website onderhoud en beheer ook snelheid meet.
Drie sites, drie routes
Een zelfstandige met een WordPress-site. Meestal staat de server bovenaan: gedeelde hosting zonder paginacache. Kies eerst een cacheplugin of een host met cache, dan de beelden. Een middag werk; is je site oud en zwaar, vergelijk dan met een nieuwe in website op maat of WordPress.
Een webshop op Shopify of WooCommerce. De server is meestal in orde of niet in je handen; de winst zit in productfoto's en apps die elk een script laden. Test een productpagina, niet alleen je homepage, en schrap per app wat geen omzet brengt. Meer in SEO voor webshops.
Een dienstbedrijf met tien man en klanten in het buitenland. Test vanaf Europa wat je klanten in Nederland of Duitsland krijgen: een site op een server ver weg voelt snel op kantoor en traag bij hen. Een static export op een CDN haalt de servertijd bijna weg.
Snelheid winnen deze week
- Test je zwaarste paginaNiet alleen je homepage: de pagina waar je bezoekers uit Google binnenkomen.
- Verklein je eerste beeldOp de getoonde maat, in WebP of AVIF, zonder loading=lazy.
- Schrap een scriptDe tracker van een vorig bureau of de chat die niemand gebruikt.
- Zet compressie en cache aanEen instelling bij je host of CDN, meteen winst voor elke pagina.
- Kijk in Search ConsoleHet rapport Core Web Vitals toont welke groepen pagina's traag zijn bij echte bezoekers.
Snelheid van je website: vragen en antwoorden
Wat is een goede laadtijd voor een website?
Google zegt: het grootste element binnen 2,5 seconden, een reactie op een tik binnen 200 milliseconden en een verspringing van hooguit 0,1, bij drie op de vier bezoeken. De server begint best binnen 0,8 seconde te antwoorden.
Waarom verschilt dit van PageSpeed Insights?
PageSpeed Insights laadt je pagina in een browser en toont daarboven de cijfers van echte bezoekers. Deze test meet de server en het gewicht, zonder browser, vanuit Europa. Hier zie je welk bestand het probleem is, daar hoe de bezoeker het merkt.
Waarom is mijn site snel op wifi en traag op een gsm?
Op wifi valt het gewicht weg, op een gsm in de trein niet. Daarom rekent de test het gewicht om naar trage 4G, 1,6 megabit per seconde: een foto van 1,4 MB doet er dan alleen al 7,3 seconden over.
Telt de snelheid van mijn website mee in Google?
Ja, Google gebruikt de Core Web Vitals in zijn rankingsystemen. Maar de meest relevante pagina wint, ook als ze trager is. Snelheid beslist vooral tussen pagina's die de vraag even goed beantwoorden.
Waarom meet de test vanuit Stockholm?
Onze functie draait in een Europees datacenter van AWS in Stockholm. Een bezoeker in Gent zit dichter bij een server in West-Europa, dus zijn tijd tot de eerste byte kan iets lager liggen dan wat de test toont.
Wordt mijn adres bewaard?
Nee. We tellen alleen hoeveel tests er per dag gebeuren, niet welke sites. Bestanden van andere servers halen we niet op, we tellen ze alleen.