TTFB (Time to First Byte)
TTFB, Time to First Byte, is how long a browser waits between starting to load a page and receiving the first byte of the answer. Nothing else on the page can begin until then, so a slow first byte holds back every later figure.
- By
- WP Ministry
- Published
In short
- TTFB counts everything before the first byte of a page arrives. 0.8 seconds or less is good and more than 1.8 seconds is poor, as a rough guide.
- It is not a Core Web Vital, but it is the first part of Largest Contentful Paint, so a slow one makes that figure slow too.
- WordPress and Lighthouse both use 600 milliseconds, for the server's own response. That is a narrower measurement than TTFB.
TTFB, Time to First Byte, is the time from the moment a browser starts navigating to a page until the first byte of the response arrives. It adds up everything before that byte: any redirects, the DNS lookup, the connection and its TLS negotiation, and the wait while the server produces the page.
Nothing else on the page can start until that byte arrives, so every other loading figure comes after it. Google's guide to the metric gives 0.8 seconds or less as good and more than 1.8 seconds as poor, and calls both a rough guide. TTFB is not one of the Core Web Vitals.
Where you meet it
- PageSpeed Insights, in the field data. Time to First Byte is reported from real visits, beside the Core Web Vitals. Google's documentation marks it as experimental.
- PageSpeed Insights, in the lab report. The insight "Document request latency" has a line that reads "Server responds quickly" or "Server responded slowly", with the time it observed. It fails above 600 milliseconds. The insight "LCP breakdown" has a row named "Time to first byte".
- Older reports and guides. Before Lighthouse 13, released in October 2025, that check was an audit named "Reduce initial server response time".
- WordPress. Go to Tools, then Site Health. Since version 6.1, a test there requests the home page three times and reports the median, under a result such as "Page cache is not detected and the server response time is slow". Its threshold is also 600 milliseconds.
The two numbers measure different things. The 600 milliseconds is for the server's own response. The 0.8 seconds is for the whole wait, which Chrome's documentation says also takes in the DNS lookup and any redirects. A site can pass one and fail the other.
What goes wrong
- There is no page cache. Without one, WordPress builds the page afresh for every visitor. A page cache saves the finished page and serves that copy. WordPress caching plugins compared covers the choice.
- The server is slow all the same. How to reduce server response time times each part of the wait and works through the fixes in order.
- The cause is the hosting, not the site. WordPress hosting problems shows how to tell which it is.
- A redirect comes first. The browser has to make a second request at the new address before the page is even asked for. The redirect checker shows every hop.
- Largest Contentful Paint fails with it. TTFB is the first part of that figure. See how to fix Largest Contentful Paint.
How to look at yours
curl -s -o /dev/null -w "%{time_starttransfer}\n" https://example.com/This prints, in seconds, the time from the start of the request until the first byte was received. Use the page's final address, because curl does not follow a redirect unless told to. Run it several times: one run is not a measurement.
Common questions
Is TTFB a Core Web Vital?
No. The Core Web Vitals are Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift. Google's guide says a site need not meet the good TTFB threshold, so long as TTFB does not stop those three from doing well.
Why does Site Health say the response time is fine when PageSpeed Insights says TTFB is slow?
They measure different things. Site Health times a request the site makes to its own home page, against 600 milliseconds. The field data in PageSpeed Insights comes from real visitors, and for them TTFB also includes the DNS lookup, the connection and any redirects.
Is TTFB the same as server response time?
No. Server response time is one part of TTFB: the wait while the server produces the page. TTFB adds what comes before it, which is why its threshold is longer.

