Time to first byte is the delay between a browser asking for a page and the first byte of the answer arriving. It is the earliest moment a visitor can know your site exists. Everything else they experience — images, scripts, the page painting — happens after it.
What the number includes
TTFB is not one thing; it is a chain, and any link can be the slow one:
- DNS lookup — turning your domain name into an address. Usually 10–50 ms, but a slow or distant resolver can push it past 100.
- TCP connection — one round trip to the server before anything is sent.
- TLS handshake — establishing the encrypted session. On HTTP/2 this is one more round trip; on older setups, two.
- Server time — your application building the response: database queries, templates, third-party calls.
- The first byte travelling back.
The first three are dominated by distance. A round trip from London to a server in London is a few milliseconds; from Sydney to that same server it is around 250 ms, and TTFB includes two or three of them before your code has run a single line.
What counts as good
Google's published guidance is straightforward: under 800 ms is good, over 1.8 seconds is poor, and the space between is "needs improvement". Those thresholds are measured from real visitors, so they already include the distance problem.
For a page served from a content delivery network close to the visitor, 100–300 ms is normal. For a dynamic page hitting a database on a single origin, 300–800 ms is typical and fine. If you are regularly above a second, something specific is wrong and it is usually findable.
Why it varies by visitor
This is the part most speed tools hide. A single measurement from one location tells you how fast your site is from there. Your server in Frankfurt looks quick from Paris and slow from São Paulo, and both are true. If a customer says "your site is slow" and your test says it is fast, you are probably standing in different places.
The fix is to measure from where your visitors are, continuously rather than once, so you can see "slow from Asia since Tuesday" as a distinct fact from "down everywhere".
What actually moves it
- A CDN or edge cache in front of anything static, and in front of dynamic pages that can tolerate a short cache. This is the single biggest lever for distant visitors.
- Keep connections warm. HTTP/2 and HTTP/3 reuse one connection for everything; check your server actually negotiates them.
- Look at the slowest database query on your slowest page. Server time is usually one query, not many.
- Fewer redirects. Every redirect before the final page is a full extra TTFB.
httptohttpstowwwis three requests for one page. - DNS with a short chain. A CNAME pointing at a CNAME pointing at a load balancer costs lookups.
Measuring it
You can see your own TTFB right now: UpConduit's free speed test breaks a page load into DNS, connect, TLS, first byte and download, and lists the fixes worth making. An account watches it continuously from seven regions, so the "slow from Sydney" conversation happens before the customer has it.