TTFB Test
This TTFB test shows how long real visitors wait for the first byte of your page. It reads the Time to First Byte from Google's Chrome UX Report for the address you enter and for the whole site, and rates it against the web.dev thresholds. Your server is never contacted.
Rating per web.dev: good up to 800 ms, needs improvement up to 1,800 ms, poor above. TTFB is not a Core Web Vital, but it delays FCP and LCP. Source of the thresholds.
To see what the server time depends on and how your pages do in the lab, run the free website speed test with a competitor comparison.
How the TTFB test uses Chrome UX Report data
For every page load, Chrome records the time between the start of the navigation and the first byte of the response. Google aggregates these values over 28 days in the Chrome UX Report. The checker queries them for your address and reports the 75th percentile, the value that three out of four page loads beat.
If the single URL has too few visits, its row stays empty and the origin row shows the value for the whole site. Switching between mobile and desktop tells you whether phone users wait longer, for example because a mobile connection takes more round trips to set up.
Reading the TTFB result: percentile, distribution and thresholds
A TTFB up to 800 milliseconds is good, up to 1,800 milliseconds needs improvement, and anything above is poor. The bar under the value splits all page loads into these three ranges. A good 75th percentile with a wide red segment means some visitors wait much longer, typically on pages that are not served from a cache.
When the URL is well above the origin, that one page is expensive to generate, such as a search, a cart or a page the page cache skips. When both values are high, look at the server, the hosting plan or a redirect chain in front of the actual page.
Field data versus lab tests: why the numbers differ
Field TTFB covers everything before the first byte: redirects, DNS lookup, connection, TLS and the server's response time. A request with curl or in DevTools runs from one location, often against a warm cache, and usually comes out lower. Use the lab to verify a change, and the field data to see what your visitors actually get.
What drives a slow TTFB and how to reduce server response time with page caching, a CDN and better hosting is covered in the guide to Time to First Byte.
TTFB of other websites for comparison
In PerfDelta's measurements, 61% of 5,893 websites have a good mobile TTFB. The median is 694 ms, and 6% have a poor TTFB above 1.8 seconds. All figures are in the website speed statistics.
FAQ
What is a good TTFB?
According to web.dev, a Time to First Byte up to 800 milliseconds at the 75th percentile is good and up to 1,800 milliseconds needs improvement. TTFB is not a Core Web Vital, but it delays FCP and LCP because the browser cannot start building the page before the first byte arrives.
Why does the TTFB test show no data for my site?
The Chrome UX Report only includes pages and sites with enough visits from Chrome. Check the spelling with and without www. If there is no field data at all, measure TTFB in the lab with DevTools or curl.
Does the test put load on my server?
No. The test never requests your website; it only reads public values from Google's Chrome UX Report. That also makes it suitable for checking competitors.
See also: Core Web Vitals Test.
How do your competitors compare? The Core Web Vitals Benchmark puts up to five websites side by side using real-user data.
Guides for every metric and finding are in the Website Speed Optimization.
A free account saves your tests and shows how your values change from one test to the next. Daily monitoring with field data and alerts starts with the Solo plan.