What is TTFB and what is a good value?

Time to First Byte (TTFB) is the time between a browser requesting a page and receiving the first byte of the response. According to web.dev, a TTFB of 0.8 seconds or less is good, and above 1.8 seconds is poor. TTFB is not a Core Web Vital, but a slow one delays everything that follows.

Why it matters

Nothing can be drawn until the first bytes of the HTML arrive, so TTFB is the starting line for First Contentful Paint and Largest Contentful Paint. If the server takes two seconds to answer, a good LCP of 2.5 seconds becomes very hard to reach.

TTFB includes more than your server's thinking time. It is the sum of:

any redirects before the final page
DNS lookup for the host name
the connection set-up and the TLS handshake for HTTPS
the wait while the server (or the CDN edge) builds or finds the response

That means a chain of redirects or a distant server can raise TTFB even when your application is quick.

How to check

Open PageSpeed Insights. The field data block can show TTFB from real visits, and the lab report lists "Reduce initial server response time" when the main document is slow.
In Chrome DevTools, open the Network panel, click the main document and read the Timing tab. "Waiting for server response" is the server wait portion.
From a terminal, you can read timings with curl:

curl -o /dev/null -s -w "dns: %{time_namelookup}\nconnect: %{time_connect}\ntls: %{time_appconnect}\nttfb: %{time_starttransfer}\n" https://example.com/

Test several pages, not only the home page, and repeat a few times. A single sample can mislead.

Ways to lower it

Cache full pages or fragments so the server does not rebuild them for every visitor.
Serve cacheable pages from a CDN edge close to the visitor.
Remove unnecessary redirects, such as HTTP to HTTPS followed by non-www to www, by pointing links straight at the final address.
Speed up slow database queries and server-side code.
Move from an overloaded shared plan if response times are slow at every hour.

Common mistakes

Treating TTFB as a pass or fail Core Web Vital. It is a diagnostic metric.
Measuring only from your own office, near the server.
Ignoring the extra redirect hop that counts toward the number.
Blaming the host before checking uncached database-heavy plugins or pages.

Frequently asked questions

Is TTFB the same as server response time?

Not exactly. Server response time is the wait for the server itself, while TTFB also includes redirects, DNS and connection set-up before that wait.

Does a CDN improve TTFB?

It can, when pages are cacheable and served from an edge location near the visitor. For uncached or personalised pages the request still goes back to your origin server.

Why does TTFB vary between tests?

Cache state, server load, network route and distance all change between tests. Compare several runs and look at field data rather than a single number.

Crawvix's scan checks that server response time is acceptable. To try it, Try the free website sample.