Je website voelt voor jou misschien prima snel, maar dat zegt nog niet zoveel over hoe bezoekers hem ervaren. Op jouw laptop, met goede wifi en een warme browsercache, laadt een pagina vaak sneller dan bij een nieuwe bezoeker op mobiel. Bij Webtify krijgen we daarom regelmatig de vraag: hoe test je de snelheid van je website nou op een manier waar je echt iets aan hebt?
Het korte antwoord: je kijkt niet alleen naar één laadtijd, maar naar meerdere meetpunten. In deze blog leggen we uit welke tools je kunt gebruiken, waar je op moet letten en wanneer een website grofweg slecht, gemiddeld of goed presteert.
Waarom alleen ‘laadtijd’ eigenlijk te simpel is
Veel ondernemers vragen vooral: hoeveel seconden mag een website laden? Begrijpelijk, maar moderne snelheidstesten kijken breder. Google gebruikt in PageSpeed Insights namelijk zowel labdata als echte gebruikersdata, en beoordeelt daarbij onder meer hoe snel de grootste zichtbare content verschijnt, hoe stabiel de pagina blijft en hoe snel iemand echt kan klikken of typen.
Dat betekent dus dat een website technisch “geladen” kan zijn, terwijl hij voor bezoekers nog traag aanvoelt. Juist daarom is het slim om verder te kijken dan alleen een stopwatch of een gevoel.
Met welke tools test je je websitesnelheid?
De bekendste tool is PageSpeed Insights. Die tool laat zien hoe je pagina scoort op mobiel en desktop en combineert Lighthouse-labdata met praktijkdata uit het Chrome User Experience Report als die beschikbaar is.
Een tweede handige tool is GTmetrix. Daarmee kun je goed zien hoe bestanden laden, welke requests zwaar zijn en waar vertraging ontstaat. Vooral de waterfall-weergave is handig als je echt wilt uitzoeken waar het probleem zit.
Werk je in Chrome, dan kun je ook Lighthouse in DevTools gebruiken. Dat is vooral handig als je tijdens het bouwen of aanpassen snel opnieuw wilt testen. Bij Webtify gebruiken we in de praktijk meestal een combinatie van deze tools, omdat één rapport zelden het hele verhaal vertelt.
Welke cijfers zijn het belangrijkst?
Als je test in PageSpeed Insights, zijn dit de belangrijkste signalen om naar te kijken:
- LCP (Largest Contentful Paint): hoe snel het belangrijkste zichtbare deel van de pagina in beeld komt
- INP (Interaction to Next Paint): hoe snel de pagina reageert op interactie, zoals klikken
- CLS (Cumulative Layout Shift): hoeveel de layout onverwacht verspringt
- TTFB (Time to First Byte): hoe snel de server de eerste reactie geeft
Google hanteert hiervoor duidelijke richtlijnen. LCP is goed bij 2,5 seconden of sneller, INP is goed onder 200 milliseconden en CLS is goed bij 0,1 of lager. Voor TTFB geldt dat 0,8 seconde of sneller een goede waarde is.
Wat is dan slecht, gemiddeld of goed?
Voor ondernemers is dit vaak de praktischste indeling:
- Goed: je belangrijkste pagina’s voelen direct bruikbaar, LCP zit rond of onder 2,5 seconden en de site reageert vlot zonder verspringende blokken.
- Gemiddeld: de site is bruikbaar, maar niet echt snel. Denk aan een LCP tussen 2,5 en 4 seconden of een merkbaar trage eerste interactie.
- Slecht: bezoekers moeten zichtbaar wachten, content schuift heen en weer of klikken reageren traag. Vaak zie je dan een LCP boven 4 seconden, een hoge INP of serververtraging.
Zie deze cijfers niet als losse rapportpunten, maar als signalen. Een homepage kan bijvoorbeeld redelijk scoren, terwijl een dienstenpagina of webshopcategorie veel trager is.
Hoe test je je website op een nuttige manier?
Een goede snelheidstest doe je niet één keer. Test bij voorkeur meerdere pagina’s, zoals je homepage, een landingspagina, een contactpagina en eventueel een product- of categoriepagina. Zo ontdek je of het probleem overal zit of vooral op zwaardere pagina’s.
Test daarnaast altijd op mobiel. Google laat mobiele prestaties niet voor niets apart zien: veel websites voelen op desktop prima, maar zijn op mobiele verbindingen ineens een stuk trager.
Wat we bij Webtify ook vaak zien: ondernemers testen direct na een aanpassing en schrikken van een score, terwijl cache of zware afbeeldingen nog meespelen. Kijk daarom niet alleen naar de totaalscore, maar ook naar de uitleg eronder. Heb je bijvoorbeeld veel grote afbeeldingen, dan is het slim om ook te kijken naar afbeeldingen verkleinen voor je website. Werk je met Divi, dan sluit dit ook goed aan op onze tips voor een snelle Divi website.
Veelgemaakte fout: blindstaren op de PageSpeed-score
Een PageSpeed-score van 100 is geen doel op zich. Het gaat erom of je website voor echte bezoekers snel genoeg werkt. Een site met score 78 kan in de praktijk prima presteren, terwijl een score 90 alsnog een trage beleving geeft op bepaalde pagina’s of apparaten.
Daarom is het slim om snelheid ook te combineren met andere inzichten, bijvoorbeeld via Google Analytics of Google Search Console. Dan zie je beter welke pagina’s veel verkeer krijgen en waar prestatieproblemen echt impact hebben.
Van meten naar verbeteren
De snelheid van je website testen begint dus met de juiste tools en de juiste verwachtingen. Kijk naar PageSpeed Insights voor de belangrijkste gebruikerssignalen, gebruik GTmetrix voor extra technische verdieping en test altijd meerdere pagina’s op mobiel én desktop.
Zie je dat je site in de middelste of slechte zone valt? Dan is dat meestal geen reden voor paniek, maar wel een duidelijk signaal om te optimaliseren. Denk aan afbeeldingen, caching, scripts, hosting of je theme-opbouw. En juist daar zit vaak het verschil tussen een website die “wel online staat” en een website die echt prettig werkt en beter converteert.
Voor de meeste websites is PageSpeed Insights de beste eerste stap, omdat je daar mobiel- en desktopscores ziet en vaak ook echte gebruikersdata. GTmetrix is daarnaast handig als je technisch dieper wilt kijken naar requests en laadtijd per onderdeel.
Dat hangt af van wat je meet, maar als vuistregel geldt dat een website goed presteert als de belangrijkste content binnen ongeveer 2,5 seconden zichtbaar is. Duurt dat richting 4 seconden of langer, dan is er meestal ruimte voor verbetering.
Allebei, maar mobiel is vaak het belangrijkst. Veel websites laden op desktop nog prima, terwijl ze op mobiel duidelijk trager aanvoelen door zwaardere scripts, afbeeldingen of een langzamere verbinding.
Dat komt doordat labtests momentopnames zijn. Factoren zoals netwerkcondities, serverreactie en ingeladen scripts kunnen per test iets verschillen. Daarom is het slimmer om naar patronen en terugkerende knelpunten te kijken dan naar één losse score.
Veelvoorkomende oorzaken zijn te grote afbeeldingen, te veel scripts, zware plugins, trage hosting en slecht ingestelde caching. Ook een rommelige opbouw van pagina’s of thema’s kan de prestaties flink vertragen.