TTFB checker
Measure your site’s Time to First Byte from 15 locations on 6 continents at once. For each one you see where the time goes: DNS lookup, connection, TLS handshake and your server’s own response time.
Watch it every minute
Monitor response time from the same 15 locations and get told when it slows down. 650,000 free credits every month.
What is TTFB?
Time to First Byte is the wait between asking for a page and the first byte of the answer. Nothing can render before it, so a slow TTFB makes everything after it slow too.
What is a good TTFB?
We rate the median of all locations, so one far-away location doesn’t decide it. Our probes sit in data centres on fast networks, so we rate the server’s answer on a stricter scale than Google’s, and show both.
Google’s web.dev threshold: good up to 800 ms, needs improvement up to 1800 ms, poor above. It is measured in real visitors’ browsers, slow mobile networks and redirects included, so it is looser. Every result shows it too.
Fifteen fresh visits, timed phase by phase.
Each probe requests your page at the same moment as a new visitor would: new DNS lookup, new connection, nothing in the browser cache. When the address redirects, for example to https://www., we follow it, time the final page and tell you how long the redirects took. The Cache column shows whether your CDN answered from its cache (HIT) or passed the visit to your server (MISS, DYNAMIC).
Finding you
Looking up your domain’s address. Slow here means a slow DNS provider.
Reaching you
Opening the TCP connection: about one round trip to your server, so it grows with distance.
Securing it
The HTTPS handshake, one or two more round trips.
Your answer
From sending the request to the first byte back: your application and hosting.
The sum
TTFB is all of the above. Total adds downloading the page and any redirects.
How to improve TTFB
Read the columns: they tell you which fix applies.
“Server” high everywhere
Your back end is slow: cache pages, fix slow database queries, or move to faster hosting.
Fast nearby, slow far away
That’s distance. A CDN, or a server closer to your visitors, cuts Connect and TLS.
Behind a CDN but still slow
If Connect and TLS are tiny but Server is high, the CDN isn’t caching the page and every visitor waits for your origin.
DNS high
Use a fast DNS provider and keep your records’ TTL reasonable.
TLS high
Enable TLS 1.3 and session resumption, and serve a short certificate chain.
Redirect chains
Link straight to the final address, so visitors skip the extra round trips.
Google says 800 ms is good. Why do you rate stricter?
Google’s 800 ms is for what real visitors see in their browsers, on any network, phones on 4G included. Our probes measure from data centres, where the network adds little, so most of what you see is your server. For that, under 200 ms is excellent and under 500 ms is good. Each result gives both ratings.
Why is my TTFB different from Google PageSpeed?
PageSpeed measures from one place, often with cached connections, and lab tools add their own delays. We measure fresh visits from 15 places at once, so you see how far-away visitors experience your site.
Does the result change between tests?
A little. Networks and servers vary from second to second. For a trend, monitor the site: we record response time every minute from the same locations.
Can I share a result?
Yes. Every test gets its own link, kept for 7 days.
Is there a limit?
A few tests per hour from your network, and one fresh test per site per minute for everyone. We only send normal web requests to ports 80 and 443.