Een goede responstijd voor een website, gemeten als time to first byte voor een HTML-pagina, ligt grofweg onder de 200 milliseconden voor een gecachete pagina en onder de 600 milliseconden voor een dynamische pagina. Volgens de richtlijnen van Google op web.dev is een time to first byte van 0,8 seconden of minder goed. Boven ongeveer een seconde beginnen bezoekers het wachten te merken voordat er iets op het scherm verschijnt. Deze getallen zijn vuistregels, geen harde grenzen: belangrijker is dat je responstijd stabiel is en dat je merkt wanneer hij afwijkt.
In deze gids lees je wat responstijd meet, hoe het verschilt van laadtijd, waarom je monitor en je browser verschillende getallen geven, en hoe je het bijhoudt zodat vertragingen worden opgelost voordat ze uitgroeien tot storingen.
Responstijd is niet hetzelfde als laadtijd
De twee begrippen worden vaak door elkaar gehaald, maar ze meten iets anders.
Responstijd is hoe lang de server erover doet om één verzoek te beantwoorden. Voor een monitor is dat meestal de tijd vanaf het versturen van het verzoek tot het antwoord binnen is.
Laadtijd is hoe lang de browser erover doet om een bruikbare pagina te tonen. Daarin zit de responstijd van het HTML-document, plus het downloaden en uitvoeren van CSS, JavaScript, lettertypen en afbeeldingen, vaak tientallen extra verzoeken.
Een pagina kan een snelle responstijd en een trage laadtijd hebben, bijvoorbeeld als de server in 150 milliseconden antwoordt maar de pagina daarna drie megabyte JavaScript laadt. Onze tips voor een snellere website gaan over die front-endkant. Het omgekeerde gebeurt ook: een goed geoptimaliseerde frontend kan een server die vier seconden nodig heeft om de HTML te maken niet verbergen. Responstijd is het deel dat je server en je hosting bepalen. Laadtijd is het deel dat je frontend bepaalt. Beide zijn belangrijk, en ze vragen om andere oplossingen. Voor de laadtijd draait de paginasnelheidsmonitoring van Uptimecheck elke dag Google Lighthouse op mobiel en desktop en waarschuwt je als de mobiele score van een pagina onder je grens zakt.
Wat er in time to first byte zit
Time to first byte, of TTFB, is de tijd vanaf het begin van het verzoek tot de eerste byte van het antwoord binnenkomt. Die bestaat uit een aantal stappen:
DNS-lookup: de hostnaam omzetten in een IP-adres.
TCP-verbinding: de round trip om een verbinding te openen.
TLS-handshake: afspraken maken over de versleuteling voor HTTPS.
Verwerking op de server: de applicatie draait, bevraagt de database en bouwt het antwoord op.
Eerste byte onderweg: het begin van het antwoord op de terugweg.
Met curl zie je elke stap voor je eigen site:
curl -o /dev/null -s -w “dns: %{time_namelookup}s\nconnect: %{time_connect}s\ntls: %{time_appconnect}s\nttfb: %{time_starttransfer}s\ntotal: %{time_total}s\n” https://northwind.shop/
De waarden zijn cumulatief. Is tls 0,12 seconden en ttfb 0,95 seconden, dan was de server ongeveer 0,8 seconden bezig met het maken van de pagina. Dat is het getal om aan te werken. Zijn de DNS- of connect-stappen groot, dan zit het probleem in de afstand, het netwerk of DNS en niet in je applicatie. Uptimecheck splitst de responstijd van elke check op in dezelfde fasen: DNS, verbinden, TLS, server en download.
Waarom monitors en browsers andere getallen geven
Het is normaal dat je uptime monitor, de ontwikkelaarstools van je browser en een tool voor prestatietests verschillende responstijden tonen voor dezelfde pagina. De gebruikelijke redenen:
Locatie. Een check vanaf een ander continent voegt round trips toe aan elke stap hierboven. Een server in Stockholm antwoordt een bezoeker in Stockholm sneller dan een check vanaf de oostkust van de VS.
Hergebruik van verbindingen. Je browser houdt verbindingen open en gebruikt ze opnieuw. Een monitoringcheck opent vaak elke keer een nieuwe verbinding en betaalt dus bij elk verzoek voor DNS, TCP en TLS.
Caching. Je browser kan de pagina of delen ervan in de cache hebben, en een CDN kan aan sommige regio’s een gecachete kopie leveren en aan andere niet.
Wat er gemeten wordt. De ene tool meldt TTFB, een andere de totale tijd om het volledige antwoord te downloaden, een derde de laadtijd van de hele pagina.
Cookies en logins. Ingelogde gebruikers omzeilen vaak de paginacache, waardoor hun antwoorden trager zijn dan een anonieme check.
Geen van deze redenen maakt één getal fout. Waar het om gaat, is appels met appels vergelijken: dezelfde check, vanaf dezelfde locatie, door de tijd heen. Een monitor die elke minuut hetzelfde verzoek meet, geeft je een consistente basislijn, en veranderingen ten opzichte van die basislijn zijn waar je op reageert.
Redelijke doelen, als vuistregel
De bereiken hieronder zijn vuistregels voor het serverantwoord op een HTML-pagina of API-call, gemeten vanaf een locatie redelijk dicht bij je server. Ze zijn een startpunt voor je eigen basislijn, geen standaard.
Soort antwoordPrimaHet onderzoeken waardGecachete pagina of statisch bestand via CDNonder 100–200 msboven 400 msDynamische pagina (CMS, webshop, app)onder 300–600 msboven 1 sEenvoudig API-endpoint dat leestonder 100–300 msboven 800 msZoeken, rapporten, zware queriesonder 1–2 sboven 3 s
Twee kanttekeningen bij de tabel. Ten eerste: tel de netwerkafstand erbij op. Een check vanaf een ander continent kan er een paar honderd milliseconden bovenop zetten, en dat kan je applicatie niet oplossen. Ten tweede: de kolom die het meest telt, is de kolom die je zelf invult. Antwoordt je checkout normaal in 350 ms en vandaag in 900 ms, dan is er iets veranderd, ook al ziet 900 ms er op papier nog acceptabel uit.
Wat responstijden vertraagt
Als de responstijd stijgt, is de oorzaak bijna altijd een van deze:
Trage databasequeries: een ontbrekende index, een query die meegroeit met de grootte van een tabel, of een plugin die tientallen queries per pagina uitvoert.
Geen pagina- of objectcache: elk verzoek bouwt dezelfde pagina opnieuw vanaf nul op.
Externe calls tijdens het verzoek: API’s voor betalingen, verzending, zoeken of analytics die synchroon worden aangeroepen terwijl de bezoeker wacht.
Te weinig workers: verzoeken staan achter elkaar in de rij als alle workers van PHP-FPM, Node of de applicatieserver bezet zijn.
Druk op resources: CPU op de limiet, geheugen dat swapt of disk-I/O die verzadigd raakt door back-ups of het schrijven van logs.
Cold starts: serverless functies en containers die naar nul zijn geschaald, hebben tijd nodig om het eerste verzoek te starten.
Afstand: bezoekers ver van de server, zonder CDN ertussen.
Wachtrijen zijn de reden dat responstijd ertoe doet voor de beschikbaarheid. Als antwoorden trager worden, houdt elk verzoek een worker langer bezet, raakt de pool vol en moeten nieuwe verzoeken wachten of worden ze geweigerd. Een vertraging die begint als een halve seconde extra kan bij de volgende verkeerspiek eindigen als een 503 Service Unavailable-fout.
Volg de trend, niet één check
Eén trage check zegt weinig. Een netwerkhapering, een pauze voor garbage collection of een cache miss kan één verzoek traag maken. Wat je vertelt dat er iets mis is, is een patroon:
Een sprong: de responstijd schiet omhoog na een deploy, een plugin-update of een hostingwijziging, en blijft daar.
Een langzame stijging: de responstijd groeit elke week een beetje, terwijl een tabel of een log groeit.
Een dagelijks patroon: de responstijd piekt elke dag op hetzelfde uur, vaak door een back-up, een import of een cron-job die om resources concurreert.
Een regionaal verschil: één regio is traag terwijl een andere in orde is. Dat wijst op een CDN, routering of DNS in plaats van op de server.
Uptimecheck slaat de responstijd van elke check op voor elke uptime monitor en API-monitor, toont die in grafieken met de mediaan en het 95e percentiel, en de wekelijkse en maandelijkse e-mailrapporten bevatten de gemiddelde responstijd naast de uptime. Met die geschiedenis zie je een sprong op de dag dat hij gebeurt, in plaats van weken later.
Waarschuw bij aanhoudende traagheid
Een melding bij elke trage check zorgt voor ruis, en meldingen met veel ruis worden genegeerd. Waarschuw bij traagheid die aanhoudt. Een praktische aanpak:
Meet een week of twee de basislijn voor elk belangrijk endpoint.
Leg het waarschuwingsniveau duidelijk boven de normale variatie, bijvoorbeeld op twee tot drie keer de gebruikelijke responstijd.
Waarschuw alleen als de traagheid aanhoudt over meerdere opeenvolgende checks of minuten.
Stuur waarschuwingen over traagheid naar een teamkanaal, en bewaar pushmeldingen op de telefoon voor echte storingen.
Stel bij elke check een time-out in. Een antwoord dat 30 seconden duurt, is voor een bezoeker een storing, wat de statuscode ook is.
In Uptimecheck stel je per monitor een grens voor trage antwoorden in. Zijn drie checks op rij trager dan die grens, dan krijg je een melding dat de monitor traag is, en nog een als hij weer sneller wordt. Trage tijd telt niet als downtime.
Dezelfde principes gelden voor elke melding die je instelt. Onze gids over minder valse meldingen bij uptime monitoring gaat dieper in op bevestiging en drempels, en drempels voor servermeldingen kiezen legt uit hoe je grenzen instelt voor CPU, geheugen en schijf. Als responstijden stijgen, laat servermonitoring naast je uptime checks zien of de server de oorzaak is, zodat je niet hoeft te gokken tussen de database, het netwerk en de code.
Checklist voor responstijd
Meet met curl de TTFB van je belangrijkste pagina’s en endpoints, vanaf een plek dicht bij je server.
Monitor dezelfde pagina’s elke minuut en bewaar de geschiedenis.
Leg per endpoint een basislijn vast en vergelijk daarmee, niet met een algemeen getal.
Onderzoek sprongen na deploys en langzame stijgingen over weken.
Cache wat je kunt, los trage queries op en haal externe calls uit het verzoek.
Waarschuw bij aanhoudende traagheid en bij time-outs, niet bij losse trage checks.
Samenvatting
Een goede responstijd is laag voor het soort pagina, ligt dicht bij je eigen basislijn en is stabiel door de tijd heen. Als vuistregel mik je op een paar honderd milliseconden voor dynamische pagina’s en ruim daaronder voor gecachete. Meet het elke keer op dezelfde manier, let op de trend en zie een aanhoudende stijging als vroege waarschuwing, want de trage pagina van vandaag is vaak de storing van morgen.
Uptimecheck legt bij elke check de responstijd vast, zodat je naast storingen ook vertragingen ziet. Probeer het 14 dagen gratis, geen creditcard nodig.