Time to first byte is how long the browser waits before it receives anything at all. Everything else on the page is queued behind it, which is why a slow TTFB caps how good your Core Web Vitals can ever be, no matter how well the front end is built.
What the number is made of
TTFB is not one thing. It is DNS lookup, connection and TLS handshake, the request travelling to the origin, the server generating the response, and the first byte travelling back. Optimising server code when the cost is network distance is wasted effort, so separate them before you start.
A rough split is easy to get: compare TTFB from a location near the origin with TTFB from the far side of the world. If only the distant one is bad, the problem is geography, not code.
Caching at the edge is the largest single lever
For any page that is the same for everyone, the fastest possible origin is one that is not consulted. A CDN serving a cached HTML response from a nearby city eliminates both the distance and the generation time.
The reason this is not done more often is personalisation. A header showing a logged-in name makes the whole page uncacheable, for one element. The usual fix is to serve the page cached and fill the personal fragment client side, which trades a small amount of complexity for the entire TTFB.
Stale-while-revalidate is worth knowing here: serve the cached copy immediately, refresh it in the background. Visitors get an instant response and the cache is never far behind.
When the origin genuinely has to run
For pages that must be generated, the usual costs are the ones you would expect and one you might not.
- Database queries, in number rather than in individual weight. Thirty small queries with round trip latency between them beats any single slow one.
- Blocking calls to other services. An upstream API called during page generation puts its latency directly into your TTFB, and its outage into your availability. Cache the response or move the call out of the request.
- Application bootstrap. On some stacks a meaningful share of every request is spent starting up before any of your code runs. Opcode caching and a persistent process model both address this.
Where global platforms lose it
A single origin serving a worldwide audience will always be slow for the half of the planet furthest from it. Multi-region deployment fixes it properly and brings its own problem, which is data: reads distribute easily, writes and consistency do not.
For a content platform the pragmatic answer is usually a single write region with read replicas and aggressive edge caching, rather than genuine multi-master. Most CMS traffic is reads.
Measure in the field, not in a lab tool
Lab tools run on a fast connection from a chosen location and produce an encouraging number. Google judges your site on data from real devices and real networks. If the two disagree, the field data is the one that matters. That is the same principle behind our Core Web Vitals work.