What is Time to First Byte (TTFB) — the thresholds, and what the number is not

Time to First Byte (TTFB) measures the gap between a browser or crawler asking for a page and the server starting to answer: DNS lookup, connection setup, the server's own work, and the network in between. While metrics like Largest Contentful Paint (LCP) measure what a visitor sees, TTFB measures whether the answer ever started.

It is also the number most often quoted with a number attached that nobody published. Google's own performance documentation gives the thresholds, and they are not tight: a TTFB of 0.8 seconds or less is "good", more than 1.8 seconds is "poor", and the guidance says plainly that TTFB is not a Core Web Vitals metric — the thresholds are "a rough guide" to be weighed against how a site delivers its content. So the useful question is not "is my TTFB under 50ms" but "what is my first byte doing, and how long does everything after it have to wait".

The four phases

When a user or search engine crawler requests a URL, TTFB accounts for four distinct phases:

1. DNS Lookup: Resolving the domain name to an IP address.
2. TCP & TLS Handshake: Establishing a secure, encrypted connection (negotiating TLS 1.3 certificates).
3. Server Processing Time: The time required by the web server or application runtime to generate or retrieve the requested HTML.
4. Network Transit Latency: The round-trip physical transit time of the data packet across undersea fiber optic cables to the user's device.

The list above names the four costs. In the order they actually happen, they look like this:

text
DNS lookup → TCP + TLS → request → processing → response
└────────────┴───────────┴─────────┴────────────┼───────▶
                                                ▲
                                           first byte

The request's trip and the response's trip are the network transit, and they sit on either side of the server's work. The first byte lands at the moment the response starts coming back, so everything to the left of that line is what TTFB is measuring.

What a good TTFB looks like, and where the number comes from

web.dev's article on TTFB — the Chrome team's documentation, last updated 2025-11-28 — is the source for the thresholds:

Its key point is the one most sites skip: because TTFB is not a Core Web Vitals metric, a site does not have to meet the "good" threshold as long as it does not get in the way of the metrics that matter. The two cases it contrasts are the whole argument:

• A site that delivers its markup quickly and then needs JavaScript to

fill it in — a single-page application — needs the lowest TTFB it can get, because the client-side rendering has to happen after the byte arrives.

• A server-rendered site that does less client-side work can have a

higher TTFB and better FCP and LCP than a fully client-rendered one.

So TTFB is a budget, not a score. It is how much of the visitor's patience the first byte consumes before the rest of the page starts.

How to measure it

web.dev gives three ways, and the choice changes what the number means:

Two caveats that decide whether a number can be trusted at all:

• Cross-origin requests are not measurable in the field unless the

other server sends a Timing-Allow-Origin header. A resource served from a third-party origin can report a TTFB of zero.

• **CrUX and other field tools may only report the main navigation

request**, so a resource's TTFB is often missing rather than fast.

What TTFB is not

• It is not a ranking factor. Nothing in Google's own account of

generative AI features in Search, or of page experience, makes a low TTFB a position. It is what makes the metrics that are signals reachable.

• It is not a Core Web Vitals metric. The three that are are LCP, INP

and CLS, and they are measured after the first byte.

• It is not a proxy for a fast site. A 30ms TTFB in front of a

4-second render is a fast byte and a slow page.

What a low TTFB does buy is narrower and real: the markup reaches the client as early as possible, the browser starts working on the page before the network has finished, and a crawler that has a limited budget gets something to read instead of nothing.

Where a static edge changes the number

Legacy web hosts rely on origin servers located in a single datacenter (such as Northern Virginia or Frankfurt). A visitor accessing that site from Singapore or London incurs a physical speed-of-light round-trip penalty of 150 to 250 milliseconds before server processing even begins.

Zeso compiles websites to immutable static assets distributed across ${EDGE_CLAIMS.locations} Anycast edge locations worldwide. Responses are delivered from the physical city closest to the visitor, achieving median TTFBs of ${EDGE_CLAIMS.medianTtfb} — inside the "good" band of Google's own threshold by a factor of sixteen, and with no origin to wait for.

Sources

• web.dev — Time to First Byte (TTFB) — the thresholds, the lab-versus-field distinction, and the "TTFB is not a Core Web Vitals metric" key point. Last updated 2025-11-28.
• MDN — Time to First Byte glossary entry
• web.dev — How to improve TTFB