Website Response Time (TTFB) Test
Time to first byte (TTFB) is how long a visitor waits before a website starts to answer. Enter an address and we time it three times on fresh connections, split the delay into DNS, connection, encryption and server wait, and tell you which part is slowing the site down.
What to do
What time to first byte means
Before a page can appear, the browser has to find the server, connect to it, set up encryption, send the request and wait for the first byte of the answer. TTFB covers all of that. It is not the full page load, but nothing else can start until it ends, so it sets a floor for every other speed measurement. Search engines and Google’s Core Web Vitals treat a slow first byte as a sign of a slow site.
The four parts we measure
- DNS lookup: turning the domain name into a server address. Slow when the DNS provider is slow or the record has a very short cache time.
- TCP connect: opening the connection. It is mostly the physical distance between us and the server, one round trip.
- TLS handshake: setting up encryption for HTTPS. It takes one or two round trips and more on old TLS versions or servers that do not reuse sessions.
- Server wait: the time between sending the request and the first byte of the answer. This is where slow code, database queries, missing page caching and overloaded hosting show up.
How to read the rating
| Server wait | Rating | What it means |
|---|---|---|
| Up to 200 ms | Fast | The server answers almost instantly, typical of cached pages and good hosting. |
| 201 to 500 ms | Good | Fine for most sites, though dynamic pages can often be made faster. |
| 501 to 1000 ms | Slow | Visitors will notice the pause. Look at caching and database work. |
| Over 1000 ms | Very slow | The server is struggling or doing a lot of work before it answers. |
The rating is based on the server wait rather than the total, because DNS, connect and TLS depend partly on how far away the measuring point is, while server wait is mostly the site’s own work.
How to make the first byte faster
- Turn on page caching so common pages are served without running code or database queries each time.
- Put a CDN in front of the site so connections end near visitors and many requests never reach your server.
- Enable TLS 1.3 and HTTP/2 or HTTP/3, and keep connections alive so they are reused.
- Check slow database queries, plugins and external API calls made while the page is built.
- Use a fast DNS provider and a reasonable TTL, such as an hour, on your records.
- Upgrade or move hosting if the server is simply overloaded. Shared plans often show high and uneven server wait at busy times.
For your own connection, rather than a website, use the internet speed test and the bufferbloat test.
About this tool
Our server first follows any redirects to find the page the address really ends at, then requests that page three times, each on a brand new connection, so connection and TLS are timed every time. DNS shows the first lookup our server made, because repeat lookups are answered from its cache and would read as zero. The result shows the median of the three, plus the fastest and slowest total. Timings are measured from our server, so a site hosted near us will look faster here than it does to visitors on another continent. The tool only reaches public websites on the standard web ports, does not download the page body, is rate limited and stores nothing.
Frequently asked questions
What is a good TTFB?
A server wait under 200 ms is fast and under 500 ms is good. Google suggests keeping the whole time to first byte under 800 ms for a good Core Web Vitals result, measured for real visitors.
Why is my TTFB different every time?
Network conditions, server load and caching change from request to request. That is why we measure three times and show the median together with the fastest and slowest. Large differences between them point to an unstable or overloaded server.
Is TTFB the same as page load time?
No. TTFB ends when the first byte arrives. Loading the images, scripts and styles takes much longer. A slow first byte delays everything, but a fast first byte does not guarantee a fast page.
Why does the same site feel faster to me than this test shows?
We measure from our server, not from your location. Distance adds to connect and TLS time, and your browser may reuse connections and cached DNS answers that our fresh-connection test deliberately does not.
How can I lower a slow server wait?
Enable caching, use a CDN, review slow database queries and plugins, and upgrade overloaded hosting. Dynamic pages that run a lot of code on every request are the usual cause.
Does this test the speed of my own internet?
No, it tests a website. To measure your own connection, use the CHECKiOX speed test on the home page.
Related tools and guides
- Internet speed test: measure your own connection.
- Is it down? checker: status and response time.
- Redirect checker: redirects add round trips.
- DNS speed test: which resolver is fastest for you.