What is TTFB (Time to First Byte)?

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.

How to measure it

There are three ways, and each tells you something different. Browser developer tools show a single load, the command line shows the server’s raw response, and field data shows what real users experience. Decide on field data; use the other two to find the cause.

1. Chrome DevTools → Network → request → Timing → “Waiting for server response”
2. curl -o /dev/null -s -w '%{time_starttransfer}\n' https://www.example.com/
3. PageSpeed Insights → field data → Time to First Byte (75th percentile)

The thresholds are defined on web.dev: 800 milliseconds or less is good, above 1,800 milliseconds is poor, and anything in between needs improvement. The value should stay under the threshold for 75 percent of visits.

Common mistakes

• Deciding on a single measurement — the first request arrives before caches are warm and can drop noticeably on repeat; look at the median of several runs.
• Measuring only from close to the server — a server in Istanbul looks fast from Istanbul and different from Frankfurt.
• Ignoring redirects — every hop from http to https or from the bare domain to www adds to the time; measure with the address users actually type.

If you want your own site measured and fixed at the source, our Core Web Vitals optimization starts from real-user data and delivers LCP, INP and CLS against a budget.