TTFB, short for time to first byte, is a web performance metric that measures the time from the start of a navigation or request until the browser receives the first byte of the response from the server. It captures everything that happens before content can begin to arrive: redirects, connection setup, the network round trip and the server’s own processing time.
In web performance, TTFB is a foundational metric rather than a user-experience metric on its own. It does not show what the user sees, but every later milestone, including FCP and LCP, cannot happen before it, so a slow TTFB sets a hard floor under the whole loading experience.
What TTFB measures, phase by phase
For a page navigation, TTFB is measured from the navigation start to the moment the response begins, which the Navigation Timing API exposes as responseStart. It is the sum of several sequential phases, and each one can dominate in different situations.
| Phase | What happens | Typical cost |
|---|---|---|
| Redirects | Following HTTP 301 or 302 responses | One full round trip per redirect |
| Service worker startup | Booting a registered worker, if any | A few to tens of milliseconds |
| DNS lookup | Resolving the host name | Near zero when cached, 20-120 ms otherwise |
| Connection setup | TCP handshake and TLS negotiation | One to two round trips, less with HTTP/3 |
| Request travel | Request reaching the server or edge | Half a round trip |
| Server processing | Routing, queries, rendering the response | From under 10 ms to several seconds |
| First byte travel | Response starting to arrive | Half a round trip |
Because several phases depend on round-trip time, the same server can show very different TTFB values for users on a fiber connection nearby and users on a mobile network on another continent. Field data therefore always reflects network distance as much as server speed.
TTFB thresholds and how to read them
Common guidance treats a navigation TTFB of 0.8 seconds or less as good at the 75th percentile of real-user page loads. These thresholds are deliberately generous, because TTFB is a diagnostic metric and sites can still achieve good LCP with a moderate TTFB if the rest of loading is efficient.
| Rating | TTFB at 75th percentile | Interpretation |
|---|---|---|
| Good | 0.8 s or less | Server and network unlikely to limit loading |
| Needs improvement | Over 0.8 s up to 1.8 s | Noticeable share of the LCP budget consumed |
| Poor | Over 1.8 s | Good LCP becomes very difficult to reach |
Lab and field values differ substantially. A test run from a data center close to the server can report 100 ms, while real users on mobile networks see several times that. Decisions should rest on field data at the 75th percentile, with lab tests used to isolate causes.
TTFB compared with neighboring metrics
TTFB sits at the very beginning of the loading timeline. The table places it next to the related metrics in web performance that build on it.
| Metric | Measures | Depends on TTFB | Core metric |
|---|---|---|---|
| TTFB | Arrival of the first response byte | Not applicable | No |
| FCP | First text or image painted | Yes, always later | No |
| LCP | Largest content element painted | Yes, always later | Yes |
| Speed index | How quickly the viewport fills visually | Yes | No |
| INP | Responsiveness to interactions | Indirectly at most | Yes |
A useful way to analyze LCP is to split it into TTFB, resource load delay, resource load time and render delay. If TTFB alone consumes most of the LCP budget, front-end optimizations such as lazy loading or preload cannot compensate.
How to reduce TTFB
Reducing TTFB means attacking the dominant phase, which differs from site to site. Server timing headers and the browser’s network panel show whether time goes into connection setup, waiting for the server or redirects.
| Cause | Symptom | Remedy |
|---|---|---|
| No caching of HTML | Every request renders from scratch | Full-page cache or CDN edge caching |
| Distant origin server | High TTFB for far-away users only | CDN or edge rendering near users |
| Slow database queries | Long server processing time | Indexes, query caching, fewer queries |
| Redirect chains | Extra round trips before the page | Link directly to the final URL |
| Cold connections | Long DNS and TLS phases | HTTP/2 or HTTP/3, TLS 1.3, connection reuse |
| Overloaded server | TTFB rises with traffic | Scaling, queueing fixes, offloading work |
Techniques such as 103 Early Hints and streaming server responses do not shorten the server’s thinking time, but they let the browser start fetching critical resources or rendering sooner, which reduces the practical impact of a moderate TTFB.
Common misconceptions about TTFB
- TTFB is not pure server time: it includes DNS, connection setup and redirects, so a fast server can still show a slow TTFB.
- A very low TTFB is not always better: some sites flush an early, nearly empty response to lower TTFB without delivering useful content sooner.
- Single lab tests mislead: one run from one location says little about real users spread across networks and regions.
- Dynamic pages are not automatically slow: with caching, edge rendering and efficient queries, personalized pages can reach a good TTFB too.
In plain words
TTFB measures how long you wait before a website even starts answering. You click a link, your browser asks the server for the page, and TTFB is the time until the very first piece of the reply comes back.
It is like calling a shop. TTFB is the time from dialing until someone picks up and says hello. If it takes too long, it does not matter how quickly they talk afterward, because everything else starts later.
A real-world example
An online furniture store hosted on a single server in Western Europe expands to customers in North America. Field data shows a 75th percentile TTFB of about 2.1 seconds for North American visitors, compared with 0.6 seconds in Europe, and LCP on product pages is rated poor overseas.
The team analyzes the phases and finds that product pages are rendered from the database on every request and that a redirect from the bare domain adds one more round trip. They enable edge caching of product HTML with short revalidation, remove the redirect from marketing links and turn on HTTP/3. Within the next reporting period, North American TTFB drops to about 0.7 seconds, and LCP moves into the good range without any front-end changes.