TTFB test
Measure your server's time to first byte. We time a fresh request, redirects and all, then three repeats, and rate the result.
Related tools: Is my website down? · HTTP headers checker · Redirect checker · HTTP status checker · Security headers checker · Uptime calculator · All free tools
How long before the server starts answering
Time to first byte is the delay between a request being sent and the first byte of the response arriving. It covers everything before the page can start rendering: redirects, the DNS lookup, the TCP and TLS handshakes, and the time the server spends producing the response. This tool measures it from Cloudflare's network, first on a fresh request with every redirect included, which is what a first-time visitor pays, then on three repeat requests to the final URL, which shows how much of the delay is the server itself.
TTFB drifts as traffic, caches, and code change. For the failure that matters most, Upcheck probes every website every 5 minutes and alerts your team when one stops answering.
Three steps, no signup
- 01
Enter a URL
The page you want timed. A bare hostname works; https is assumed.
- 02
We time the requests
One fresh request following every redirect, then three repeats to the final URL, each timed to the first byte. Bodies are discarded.
- 03
The result is rated
Against web.dev's thresholds, with the repeat timings shown so you can tell connection cost from server time.
Frequently asked questions
What is a good TTFB?
web.dev's guidance is 800 milliseconds or less for most sites, measured the way a real visitor experiences it, redirects included. Between 800ms and 1.8 seconds needs improvement, and beyond 1.8 seconds is poor. A static page served from a CDN typically answers in well under 200ms; a server-rendered page that queries a database on every request is where TTFB usually grows.
Why is the first request slower than the repeats?
Because the first one pays for everything a new visitor pays for: following redirects, looking up DNS, and completing the TCP and TLS handshakes. Repeat requests can reuse the connection, so their time is mostly the server producing the response. A large gap points at redirects or connection setup; slow repeats point at the application or a cache that isn't being hit.
Why is my TTFB different in PageSpeed Insights or from my own computer?
TTFB depends on the distance between the client and the server, so every tool measures its own route. This test runs from a Cloudflare data centre, named in the result; PageSpeed Insights reports real Chrome users around the world; your own browser adds your connection and your location. Compare results from the same tool over time rather than numbers across tools.
How do I reduce TTFB?
Remove redirects first: every hop is a full round trip before anything loads. Then cache: serve pages from a CDN or a full-page cache so the server doesn't build every response from scratch. After that, look at what the server does per request, usually slow database queries or calls to other services. Finally, host closer to your visitors, or put a CDN in front, to cut the network time.
My site is behind Cloudflare. Is the result meaningful?
Partly. The request travels inside Cloudflare's network to the edge serving your site, so the network portion is shorter than a real visitor's. A cached page will look very fast, correctly; an uncached page still shows the time Cloudflare waits on your origin, which is the part you can do something about.
Is this TTFB test free?
Yes. No account and no limit on tests by hand; scripted use is rate limited. Upcheck's paid monitoring measures response time on every uptime probe, every 5 minutes, for every website you add, and alerts your team when one stops answering.
A fast first byte is good. A first byte at all is better.
Add your websites to Upcheck and get alerted by email, Slack, Discord, Teams, or webhook the moment one stops answering.