---
title: "Time to First Byte: the floor under all your Core Web Vitals — warmup.rocks"
description: "What TTFB is made of, what a good Time to First Byte looks like, how it caps LCP — and why edge caching is the biggest single lever to improve it."
canonical: https://warmup.rocks/blog/time-to-first-byte
---

Core Web Vitals

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

July 2026 · 8 min read · [← All posts](https://warmup.rocks/blog/)

Time to First Byte isn't a Core Web Vital itself — and 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.

## Why edge caching is the biggest lever

You can shave server think time with query optimization and faster runtimes — 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 single highest-leverage TTFB intervention on most sites is: 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 — so 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](https://warmup.rocks/blog/what-is-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](https://warmup.rocks/blog/cache-hit-ratio), 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 doesn't just move one metric — it moves every paint metric, your CWV pass rate, and the bounce behavior that correlates with them. Few optimizations compound like the first byte does.