TTFB test: see how long your server takes to answer

By Google's thresholds for real visitors: each of the three numbers is rated good at 800 ms or less, needs improvement up to 1.8 s and poor above that. The real-user number is judged at the 75th percentile of visits. Ours and Lighthouse's are single requests from a data centre, without a visitor's slow network, so they should sit well below 800 ms; the server response time finding flags a back end that needs more than 600 ms.

Each times the same wait from a different place. Ours is one request from our server in Frankfurt, connection setup included and redirects not. Lighthouse's comes from Google's PageSpeed test, run on Google's own servers. The real-user number is the 75th percentile of Chrome visitors over 28 days, with their distance, networks and redirects, so it is usually the highest, and it is the one Google ranks on.

No. The three Core Web Vitals are LCP, INP and CLS. TTFB is a supporting metric Google reports beside them, because it comes first in every page load: nothing can appear before the first byte arrives, so a slow server pushes LCP back by the same amount. When TTFB is rated poor, fix it first, and the Core Web Vitals that depend on it improve with it.

Usually because the page was not in the cache: the first request after a cache expires or a deploy has to be built by the server, and later ones are served ready-made. A CDN that has not cached the page at the nearest location adds the trip to your server too. Run the test twice; if the second is much faster, lengthen the cache lifetime or warm the cache after deploys.

This test measures from Frankfurt and adds the Lighthouse run and, where Google has it, real-user TTFB from Chrome visitors wherever they are, which is the fairest single number. For specific cities, request the page with curl from a server there and read its time_starttransfer timing, or use a monitoring service with several locations.

Because every redirect adds a full round trip before the final page even starts, and Google's real-user TTFB counts that time. A link to http://example.com that goes to https:// and then to the www address makes visitors wait for two extra responses. The test lists each hop in the chain; point your links, ads and sitemap straight at the final URL so visitors skip them.

From Frankfurt, Germany, the only test location for now. Visitors far from your server can see a slower first byte than we measure, which is why the real-user number from the Chrome UX Report is shown beside ours. A US test location is a funded unlock: it switches on for everyone once monthly donations reach its threshold on the funding page.

Then the time goes into what happens after the first byte: render-blocking CSS and scripts, large images, web fonts or heavy JavaScript. TTFB only covers the server answering, not how long the browser needs to show the page. Run the website speed test on the same address to see the filmstrip, the request waterfall and which file costs the most.

Yes, with no sign-up. getReport is funded by donations, not plans, and the complete report with all seven modules is one click away, also free. It stays at its shareable link for 12 months, is not listed publicly and carries a noindex tag, and nothing about your visitors is collected.