TTFB.
TTFB is the time between the browser sending a request and receiving the first byte from the server.
It is not a Core Web Vitals metric, but it affects all three directly: until the server responds the browser can do nothing. That makes it the foundation of performance work.
Google points to under 800 milliseconds as a good target. The live measurement for this site is 0.302 seconds; in the three managed projects the value is under 300 milliseconds as well.
The duration is a chain: redirection, domain resolution, connection setup, request transmission, server work and response transmission. Every link has its own treatment.
The most overlooked link is redirection. A two-hop chain easily doubles the time; redirection should happen at the earliest possible layer and in a single hop.
The surest way to bring server work to zero is not to produce the page at request time. Sending an already-generated file is an order of magnitude cheaper than a database query and can be cached without limit on edge servers.
Cache layers are the most powerful instrument for lowering the time: the browser cache, edge servers and the server’s own cache. On static sites the third layer is unnecessary, because the page already exists generated.
The protocol version has a direct effect too: modern protocols reduce handshake round trips and allow multiple requests over a single connection. That has also partly invalidated the classic advice to concatenate files.
Geography matters when measuring: a measurement taken close to the server does not show what distant users experience. A meaningful picture requires measurements from more than one region.
- Reduce the redirect chain to a single hop — every hop is a full round trip.
- Serve static files — the surest way to bring server work to zero.
- Use an edge cache — bring the server closer to the user.
- Verify the modern protocol — it reduces handshake round trips.
- Measure from several regions — a single point of measurement misleads.
On this site the live measurement is 0.302 seconds, and in the three managed projects the value is under 300 milliseconds as well; the figures are the result of a hosting and architecture decision, not of an optimisation effort.
A reminder: this duration corresponds to nothing the user sees — the screen is still blank. But everything after it rides on top, so every hundred milliseconds here is added directly to LCP.