Twee pagina's kunnen precies dezelfde score krijgen bij een snelheidstest en toch totaal anders presteren voor echte bezoekers. Een snelheidstest draaien is eenvoudig. Het lastige is de resultaten goed lezen: welke cijfers tellen, wat ze echt meten en waar je gegevens uit de praktijk vindt in plaats van gesimuleerde scores. Dit artikel laat zien hoe je een websitesnelheidstest uitvoert, wat elke metric in de resultaten betekent, waarom gesimuleerde scores en scores van echte bezoekers vaak verschillen en hoe je met de resultaten verbeteringen doorvoert die de mensen op je site echt merken.
Een snelheidstest is het nuttigst als je weet wat je met de uitkomst moet. Eén score uit 100 zegt op zichzelf weinig. De losse metrics achter die score, en de vraag of ze uit een simulatie of van echte bezoekers komen, bepalen of de resultaten laten zien wat je bezoekers echt ervaren. Voor achtergrond over wat de metrics meten, lees je het artikel over wat laadtijd van een pagina is en hoe je die meet.
Wat meet een websitesnelheidstest eigenlijk?
Een snelheidstest laadt een pagina in een gecontroleerde omgeving en registreert hoe lang bepaalde delen van het laadproces duren. De tool meet onder meer hoe snel de server reageert, wanneer de eerste inhoud op het scherm verschijnt, wanneer het grootste zichtbare element klaar is met laden, hoeveel de indeling tijdens het laden verspringt en hoe lang het duurt voordat de pagina op klikken reageert. Die metingen worden vergeleken met standaarddrempels, zodat je een score krijgt en verbeterpunten worden aangewezen.
Labgegevens versus veldgegevens
- Labgegevens: komen uit een snelheidstesttool. De pagina wordt vanaf een vaste locatie geladen met een gesimuleerd apparaat en een gesimuleerde verbinding. De resultaten zijn gecontroleerd en herhaalbaar, maar tonen niet alle omstandigheden van echte bezoekers
- Veldgegevens: verzameld bij echte bezoekers en samengevoegd over een voortschrijdend venster van 28 dagen. Zoekmachines gebruiken deze gegevens voor de Core Web Vitals-score en de ranking
- Een site kan 90 scoren in een labtest en toch slechte Core Web Vitals-veldgegevens hebben als echte bezoekers trage apparaten, onstabiele verbindingen of een grote afstand tot de server hebben
- Kijk altijd naar beide. Labgegevens zijn handig om specifieke problemen op te sporen. Veldgegevens bepalen wat het effect is in de praktijk en op je positie in zoekresultaten
Hoe voer je een websitesnelheidstest goed uit?
Test eerst op mobiel
- Zoekmachines gebruiken mobile-first indexing, wat betekent dat ze pagina's beoordelen op hun prestaties op mobiel
- Mobiele scores zijn voor dezelfde pagina bijna altijd lager dan scores op desktop, omdat mobiele apparaten tragere processors en wisselvalliger verbindingen hebben
- Draai zowel een mobiele als een desktoptest, maar beschouw het mobiele resultaat als je belangrijkste maatstaf
Test je meestbezochte pagina's, niet alleen de homepage
- De homepage is vaak de snelste pagina van een site, omdat die meestal minder afbeeldingen en scripts heeft dan binnenpagina's
- Productpagina's, blogberichten en landingspagina's scoren vaak flink slechter en hebben mogelijk meer invloed op bezoekerservaring en ranking
- Test de pagina's met het meeste verkeer, niet de pagina's die waarschijnlijk goed uitpakken
Voer elke test meer dan één keer uit
- Resultaten van labtests kunnen per run verschillen door de serverbelasting op dat moment, de netwerkomstandigheden op de testlocatie en de cachestatus
- Draai elke test twee of drie keer en gebruik het gemiddelde als nulmeting, in plaats van op één resultaat te vertrouwen
Test vóór en na je aanpassingen
- Bepaal een nulmeting voordat je iets aan je site verandert
- Draai dezelfde test na elke verbetering om het specifieke effect te meten
- Wacht bij veldgegevens minstens 28 dagen na een wijziging voordat je het effect beoordeelt, want de gegevens zijn een voortschrijdend gemiddelde over 28 dagen dat geleidelijk bijwerkt
Hoe lees je het resultaat van een websitesnelheidstest?
Begin bij de metrics die falen, niet bij de totaalscore
- Een totaalscore van 65 vertelt je niet wat je moet aanpassen. De afzonderlijke metrics die falen, wel
- Kijk welke Core Web Vitals in het bereik "verbetering nodig" of "slecht" zitten: LCP, INP en CLS
- Elke falende metric wijst naar een ander deel van de pagina of het laadproces om uit te zoeken
Waar elke falende metric op wijst
- Hoge Time to First Byte: de server reageert traag. Onderzoek de kwaliteit van je hosting, servercaching en de prestaties van de database
- Trage Largest Contentful Paint: het belangrijkste zichtbare element laadt te langzaam. Meestal door niet-geoptimaliseerde afbeeldingen, renderblokkerende bestanden of een trage serverreactie
- Hoge Total Blocking Time of slechte Interaction to Next Paint: JavaScript blokkeert de main thread. Grote scriptbestanden en scripts van derden zijn veelvoorkomende oorzaken
- Hoge Cumulative Layout Shift: elementen veranderen van plek terwijl de pagina laadt. Komt door afbeeldingen zonder vaste afmetingen, inhoud die laat boven bestaande elementen wordt ingevoegd of banners die dynamisch worden toegevoegd
De aanbevelingen lezen
- Snelheidstesttools tonen specifieke aanbevelingen met een geschatte tijdwinst per verbetering
- Pak eerst de aanbevelingen met de grootste geschatte winst aan, dan krijg je de meeste impact per moeite
- Sommige aanbevelingen gaan over scripts of diensten van derden waar je zelf geen invloed op hebt. Noteer ze, maar richt je op wat je zelf kunt veranderen
Wat zijn goede scores bij een websitesnelheidstest?
Drempelwaarden voor Core Web Vitals
- Largest Contentful Paint onder 2,5 seconden: goed
- Interaction to Next Paint onder 200 milliseconden: goed
- Cumulative Layout Shift onder 0,1: goed
Bereiken van de totaalscore
- 90 tot 100: goed
- 50 tot 89: verbetering nodig
- 0 tot 49: slecht
Zo gebruik je benchmarks in de praktijk
- Dit zijn absolute richtwaarden, maar je score moet beter zijn dan die van de pagina's die met jou om dezelfde zoekwoorden strijden, en niet alleen boven een algemene drempel liggen
- Zoek op je belangrijkste zoekwoord en draai snelheidstests op de pagina's die boven je staan. Is jouw LCP 3,2 seconden en die van hen 2,1 seconden, dan is dat verschil bruikbaarder dan een los scoreverschil
Een uitgebreid overzicht van wat LCP, INP en CLS meten en hoe ze worden gescoord, vind je in het artikel over wat Core Web Vitals zijn.
Hoe volg je de snelheid van je website in de tijd?
Bepaal een nulmeting voordat je gaat optimaliseren
- Noteer je huidige scores voor de pagina's die je wilt verbeteren, voordat je iets verandert
- Noteer welke metrics falen en met hoeveel
- Draai de tests na elke ronde aanpassingen opnieuw en vergelijk ze met de nulmeting om de echte verbetering te meten
Controleer veldgegevens regelmatig, niet alleen na wijzigingen
- Veldgegevens in prestatierapporten worden bijgewerkt over een voortschrijdend venster van 28 dagen
- Kijk er elke maand naar, of na elke grote wijziging in inhoud, code of hosting
- Een daling van veldscores valt vaak samen met een nieuwe grote afbeelding, een nieuw script van een derde of een wijziging in de hostingconfiguratie
Test na het publiceren van nieuwe inhoud
- Een nieuw blogbericht met niet-geoptimaliseerde afbeeldingen kan die pagina flink vertragen zonder dat andere pagina's er last van hebben
- Een nieuwe landingspagina met zware scripts kan blokkeerproblemen geven die een nulmeting van de homepage nooit zou laten zien
- Neem je snelheidstest op in het publicatieproces, dan stapelen verslechteringen zich niet ongemerkt op
Een complete gids over de verbeteringen met de meeste impact op basis van je testresultaten vind je in het artikel over hoe je de laadtijd van je website verkort. Specifiek voor problemen met afbeeldingen lees je het artikel over afbeeldingen optimaliseren voor sneller laden.
Hoe WEMASY je helpt bij het testen van websitesnelheid
Het analytics-dashboard van WEMASY toont Core Web Vitals-gegevens voor alle pagina's die op het platform zijn gebouwd, gebaseerd op veldgegevens van echte bezoekers. De scores voor LCP, INP en CLS zie je per pagina, zonder dat je externe tests hoeft te draaien. Pagina's die onder de drempel voor "goed" vallen, worden gemarkeerd met de metric die faalt, zodat je direct naar het probleem gaat in plaats van een volledig rapport door te lezen.
Omdat het platform afbeeldingscompressie, caching, minificatie en CDN-levering automatisch regelt, zijn de meest voorkomende oorzaken die externe snelheidstests aanwijzen al aangepakt. Een snelheidstest op een met WEMASY gebouwde site laat daardoor meestal problemen in de inhoud zien en geen problemen op platformniveau. Dat maakt de resultaten makkelijker om op te handelen.
Bekijk wat erbij zit op de WEMASY Websitebouwer, of vergelijk de abonnementen op de prijzenpagina.
Veelgestelde vragen
Hoe test ik de snelheid van mijn website?
Voer de URL van je website in bij een snelheidstesttool. De tool laadt je pagina onder gecontroleerde omstandigheden en geeft scores voor elke laadmetric op mobiel en desktop. Kijk naast de totaalscore naar de scores per metric: de metrics die falen, laten zien waar je je op moet richten. Voor prestatiegegevens uit de praktijk, gebaseerd op echte bezoekers, kijk je in het prestatie- of analytics-dashboard van je website, als dat Core Web Vitals-veldgegevens bevat. Met de Websitebouwer van WEMASY stel je dit direct op je eigen website in.
Wat is een goede snelheidsscore voor een website?
Een score van 90 of hoger is goed, 50 tot 89 heeft verbetering nodig en onder 50 is slecht. Voor Core Web Vitals zijn de doelen een Largest Contentful Paint onder 2,5 seconden, een Interaction to Next Paint onder 200 milliseconden en een Cumulative Layout Shift onder 0,1. Een pagina slaagt voor de Core Web Vitals-beoordeling alleen als alle drie de metrics in het goede bereik zitten, gebaseerd op veldgegevens van echte bezoekers.
Waarom verschilt mijn score per test?
Scores van labtests verschillen omdat de omstandigheden per run veranderen: de serverbelasting op dat moment, de netwerkomstandigheden op de locatie van de testaanbieder en de cachestatus beïnvloeden allemaal het resultaat. Als je de test meerdere keren draait en het gemiddelde neemt, krijg je een betrouwbaardere nulmeting. Veldgegevens, gebaseerd op 28 dagen metingen bij echte bezoekers, zijn stabieler en een betere indicator van consistente prestaties voor je ranking.
Waarom is mijn mobiele snelheidsscore lager dan mijn desktopscore?
Mobiele snelheidstests simuleren tragere processors en mobiele netwerkverbindingen, en dat geeft voor dezelfde pagina lagere scores dan op desktop. Zoekmachines gebruiken mobile-first indexing, dus de prestaties op mobiel bepalen je ranking. Beschouw de mobiele score als het belangrijkste resultaat om op te optimaliseren, ook als de desktopscore er acceptabel uitziet.
Wat is het verschil tussen labgegevens en veldgegevens bij een snelheidstest?
Labgegevens komen uit een gesimuleerde testrun onder gecontroleerde omstandigheden, vanaf een vaste locatie en met een vast apparaat. Ze zijn consistent en handig om specifieke problemen op te sporen. Veldgegevens komen van echte bezoekers, samengevoegd over een voortschrijdend venster van 28 dagen, en tonen het hele scala aan apparaten, verbindingen en locaties van je echte bezoekers. Zoekmachines gebruiken veldgegevens voor de Core Web Vitals-score. Een site kan goed scoren in een labtest en toch slechte veldgegevens hebben als de omstandigheden van bezoekers in de praktijk sterk afwijken van de testomgeving.
Hoe vaak moet ik een websitesnelheidstest uitvoeren?
Draai een snelheidstest na elke belangrijke wijziging aan je website: grote afbeeldingen toevoegen, nieuwe scripts installeren, van hosting wisselen of een nieuw paginatype publiceren. Voor routinecontrole is het genoeg om elke maand de veldgegevens in je analytics- of prestatiedashboard te bekijken. Veldgegevens worden bijgewerkt over een voortschrijdend venster van 28 dagen, dus vaak handmatig testen is niet nodig. Een maandelijkse controle helpt wel om verslechteringen op te merken voordat ze je ranking of bezoekerservaring raken.