Free checker · 3 checks a day, more with a free account
Response Time Checker
Measure how fast your server answers, see which phase is slow, and get the fix for your platform.
Only test sites you own or are authorised to test.
Response time is how long a visitor waits before the first byte of your page arrives: the DNS lookup, the connection, the TLS handshake, your server's own work and any redirects on the way. This checker measures each of those phases separately, three times, and tells you which one to fix first.
What it checks.
Three samples, not one
One request is a coin flip. We take three, each on a fresh connection, report the median and say whether the numbers agree (Stable, Variable or Erratic).
Every phase, every hop
DNS, TCP connect, TLS handshake, server wait and download, for each redirect as well as the final page, so you see exactly where the time goes and what the redirects cost.
Server time, separated
The wait for the first byte minus one network round trip estimates how long your application thinks before answering: the part no CDN can hide.
CDN and cache verdict
Cloudflare, CloudFront, Fastly, Akamai, Vercel, Netlify, Bunny and more, with the cache status (HIT, MISS, DYNAMIC) and the edge location when the headers expose it.
A diagnosis, with fixes
Deterministic rules name the slow phase and the likely cause (slow DNS, heavy TLS, slow server, CDN not caching HTML, redirects, no compression, no HTTP/2) with snippets for your platform.
Honest numbers
Two published scales side by side (our lab scale and Google's field threshold) with why they differ, and a firewall challenge is reported as blocked, never as slow.
Methodology.
Method v1.0. From our probe in AWS US East, 3 GET requests one after another, each on a new TCP and TLS connection, following redirects one by one. Each phase is timed from the socket events with a high-resolution clock: DNS (this request's own lookup), connect (TCP handshake), TLS (handshake), wait (request sent to first byte), download (first byte to last). Time to first byte = DNS + connect + TLS + wait of the final request; we report the median of the samples that got an answer. No letter grades: they are arbitrary. The result is the band on the published scales below.
Beside the cold median, never inside it: the first sample also sends two more requests on its kept-alive connection (warm: no DNS, TCP or TLS) and opens one more connection offering its TLS session (resumption); a fourth request goes over HTTP/2 when the server offers it; and any 103 Early Hints before the final answer are recorded. The cold method stays the same, so results remain comparable with earlier checks.
Time to first byte (lab)
- Excellent under 200 ms
- Good under 400 ms
- Fair under 800 ms
- Slow 800 ms or more
Server time
- Excellent under 100 ms
- Good under 250 ms
- Fair under 500 ms
- Slow 500 ms or more
Google field threshold
Good up to 800 ms, needs improvement to 1800 ms, poor above, at the 75th percentile of real Chrome users. We apply it to our time including redirects, as field data does.
Diagnosis rules
| RT-DNS-SLOW | DNS lookup over 100 ms (median) | Anycast DNS provider; shorter CNAME chains; sensible TTLs |
| RT-TLS-HEAVY | TLS handshake over 150 ms (median) | TLS 1.3, ECDSA certificate, short chain, OCSP stapling, session resumption |
| RT-SERVER-SLOW | estimated server time (wait minus one round trip) over 500 ms | page cache, object cache, slow database queries, worker pool size, serverless cold starts |
| RT-CDN-NOT-CACHING | a CDN answers but the HTML is MISS, DYNAMIC or BYPASS and the wait is over 200 ms | Cache-Control: public, s-maxage=…; a cache rule for HTML; check cookies and Vary |
| RT-NO-CDN | no CDN detected and the connection takes over 50 ms (the origin is far from the probe) | put a CDN in front; cache HTML where the content allows |
| RT-REDIRECTS | one or more redirect hops before the final page | link to the final URL; one hop from http:// straight to the final https:// address |
| RT-NO-COMPRESSION | HTML served without gzip, br or zstd | enable Brotli (or gzip) for text types |
| RT-NO-H2 | the server does not offer HTTP/2 over ALPN | enable HTTP/2 on the web server or CDN |
| RT-ERRATIC | the three samples spread widely (coefficient of variation over 0.35, or one over twice the median) | look for a cold cache, a busy server or a flapping upstream; run the check again |
A firewall challenge or block page is reported as Blocked and its timing is never used.
Free JSON API.
Without a key or an account: 3 scans a day with this checker. A free key gives 60 an hour, or 600 with a work email. Every answer carries X-RateLimit-Limit, X-RateLimit-Remaining and X-RateLimit-Reset, and a 429 carries Retry-After. The same URL asked again within a minute returns the same scan. Tool id: response-time. One call takes three samples one after another, so it answers in a few seconds. Badge: /api/tools/v1/badge/response-time?url=example.com.
curl "https://bcdrpulse.com/api/tools/v1/response-time?url=example.com"
The answer is { id, tool, createdAt, cached, report, capture, share }: report holds the grade, findings and fixes; capture the raw probe data (every hop and header, without bodies); share the result page. A saved result: GET /api/tools/v1/result/<id>. Errors: 400 bad address, 401 a sign-up is needed, 403 an address we never scan (private or internal), 429 over the limit, 503 scanner busy. The API page has keys, badges and alerts.
Questions.
Why is this different from what PageSpeed Insights says?
PageSpeed's TTFB comes from real Chrome users at the 75th percentile, with their networks, devices and redirects. Ours is one probe in a data centre on a fresh connection. Both are right; they measure different things, so we show Google's field threshold next to our lab bands.
What counts as a good response time?
On our lab scale, under 200 ms to first byte is Excellent, under 400 Good, under 800 Fair, and more is Slow. Google's field threshold calls up to 800 ms good and over 1800 ms poor.
Which locations do you measure from?
Every check runs from AWS US East (N. Virginia). With a free account you can tick "From every region", and the same probe also answers from Europe (Ireland) and Asia Pacific (Mumbai): one more request from each, shown beside the main result. Visitors far from all three see more network time.
How is server time worked out?
The probe measures the wait between sending the request and the first byte of the answer. That wait contains one network round trip, which we estimate from the TCP connect time; what is left is the server's own thinking time. It is an estimate, labelled as one.
Why is my first sample slower?
A cold page cache, a serverless cold start or a resolver that had not cached your DNS yet. If the samples disagree a lot we say so; run the check again to see whether it settles.
Can I use it from a script?
Yes: GET https://bcdrpulse.com/api/tools/v1/response-time?url=example.com returns every sample, phase and finding as JSON. Without a key or an account: 3 a day per tool; a free key gives 60 an hour (600 with a work email).
More free checkers.
Scans come from our probe on AWS (US East by default) with the User-Agent BCDRPulseHeaders (about our scanner). We store results for 30 days so share links work, and never store page bodies. Want this checked every few minutes with alerts? Add the site as a verified asset and uptime monitoring watches it. API