Time to First Byte: the floor under all your Core Web Vitals

Time to First Byte isn't a Core Web Vital itself, yet it quietly caps two of them. The browser cannot paint what it hasn't received: LCP mathematically includes TTFB, and FCP does too. If your first byte takes 1.8 seconds, a "good" LCP of 2.5 seconds leaves you 700 milliseconds for everything else. TTFB is the floor everything else stands on.

What TTFB is made of

TTFB measures the time from navigation start until the first byte of the response arrives. It stacks up from:

1. Redirects: each one adds a full round trip before the real request even starts.
2. DNS, TCP, TLS: connection setup, mostly a function of distance to the nearest server.
3. Request travel to wherever the response actually comes from: an edge cache nearby, or an origin an ocean away.
4. Server think time: rendering, database queries, API calls. Zero for a cache hit; whatever your stack costs for a miss.

The brutal part is 3 + 4: for a cache hit at the edge, both are nearly zero: the response comes from a data center in the visitor's city, precomputed. For a miss, the request crosses the world and waits for your server to think. That's routinely the difference between 50 ms and 2+ seconds for the same URL.

What's a good TTFB?

Google's guidance for supporting good Core Web Vitals: under 800 ms at the 75th percentile, with under 200 ms as an aspirational target for fast experiences. Two things about that 75th percentile deserve attention:

• It's measured across all page loads, so your long-tail pages and far-away visitors drag the number, even if the homepage flies.
• Mobile networks add latency on top; the same page is structurally slower at p75 on mobile. Field data (CrUX, RUM) is the truth; lab tests from one location are not.

Want to see your own numbers? Our free global TTFB test measures any URL from six locations on four continents at once, including the cache status per location, so you can see why a location is slow. And the multi-location speed test goes a step further: it loads your page twice per location, so the first-vs-repeat-visit gap shows exactly what a cold cache costs you in each region.

Why edge caching is the biggest lever

You can shave server think time with query optimization and faster runtimes. That's worthy work, usually worth tens to hundreds of milliseconds. Serving from an edge cache removes both the ocean crossing and the think time in one move. That's why the TTFB fix with the biggest payoff on most sites is to make HTML cacheable at the edge and keep those caches warm.

The catch is the last four words. Edge caches are per-location and entries expire or get evicted constantly, which means exactly the visitors with the longest path to your origin (far-away, long-tail) are the ones most likely to hit a cold cache. That's the gap cache warming closes: it converts the p75/p95 tail from origin round trips into edge hits.

A realistic improvement plan

1. Measure honestly. Pull p75 TTFB from field data, segmented by country and by page group, not one Lighthouse run from your desk.
2. Kill redirects on entry paths (http→https→www chains, trailing-slash hops). Free wins, worth 100–300 ms each.
3. Cache HTML at the edge with purge-on-publish for freshness, and generous TTLs. Check your hit ratio per colo, not globally.
4. Warm the cache on a schedule matched to your TTLs, from the regions your visitors actually come from, plus after every deploy.
5. Then optimize the origin for whatever misses remain: they still happen, just rarely enough that they no longer set your p75.

The compounding payoff

Because TTFB sits under FCP and LCP, improvements cascade: cutting p75 TTFB from 1.5 s to 300 ms moves every paint metric, your CWV pass rate, and the bounce behavior that correlates with them. Few optimizations compound like the first byte does.