TTFB test
Time to first byte: how long until the server starts sending your HTML. Three fresh requests, split into DNS, connect, TLS and server wait.
What's inside a first byte
TTFB isn't one number — it's a stack of round trips plus server work. Change the conditions and watch which part dominates.
- DNS 80 ms
- TCP 80 ms
- TLS 1.3 80 ms
- Request travels 40 ms
- Server work 200 ms
- First byte travels 40 ms
TTFB ≈ 520 ms good
Network setup and server work are balanced here. Try a long round trip or a slow backend.
How to reduce server response time
- Cache the HTML. A page served from a CDN cache skips your application entirely; server work drops to a few milliseconds.
- Remove redirects. Each hop repeats connection setup. Link to the canonical
https://URL with or withoutwww— whichever you actually serve. - Profile the backend. If wait minus one round trip is over ~300 ms, the time is in your code: slow queries, uncached API calls or cold serverless starts.
- Upgrade the transport. TLS 1.3 saves one round trip over TLS 1.2; HTTP/2 and HTTP/3 let one connection carry every request.
- Move closer. Round-trip time is physics — light in fibre covers roughly 200 km per millisecond. Host near your audience or at the edge.
TTFB feeds directly into First Contentful Paint and Largest Contentful Paint: nothing can paint before the first byte arrives.
Questions developers ask
What is a good TTFB?
Google's web.dev guidance is that 0.8 seconds or less at the 75th percentile is good and more than 1.8 seconds is poor, measured from navigation start in real browsers. That figure includes redirects, DNS, connection setup and the server's own processing time.
What causes high TTFB?
In order of how often we see it: the server building the page on every request (uncached CMS or framework rendering, slow database queries, calls to other APIs), serverless cold starts, redirects before the real page, a server far from the visitor so every round trip is long, slow DNS, and TLS 1.2 instead of 1.3. The phase table in the result tells these apart: long DNS, connect or TLS point at the network; a long server wait points at your application.
How do I check TTFB in Chrome DevTools?
Open DevTools (F12), go to the Network tab, reload the page and click the first request (the HTML document). In the Timing tab, "Waiting for server response" is the server wait; the rows above it are queueing, DNS, initial connection and SSL. Chrome's web-vitals library and the Performance panel report TTFB as everything up to responseStart, connection setup included.
Is TTFB a Core Web Vital?
No. The Core Web Vitals are LCP, INP and CLS. TTFB is a diagnostic metric: Google lists it on web.dev as a foundation for LCP and FCP, because nothing can render before the first byte arrives, and the Chrome UX Report publishes it alongside the vitals.
Why does this test run three times?
Server response time varies between requests. We make three fresh requests, each with a new connection, and report the median so one slow outlier (a cold cache, a busy worker) doesn't decide the result. The spread between samples is shown too.
Does TTFB include DNS and TLS?
It depends who is measuring. In Chrome's Navigation Timing, TTFB is responseStart minus navigation start, so it includes redirects, DNS, TCP and TLS. In a DevTools or HAR waterfall, "Waiting (TTFB)" is only the time after the request was sent. This tool shows both: the full figure and the wait-only phase.
How do I reduce server response time?
Cache full HTML pages at a CDN edge where possible, speed up the slowest database queries, avoid redirects, enable HTTP keep-alive, use TLS 1.3, and host close to your users. If the wait phase is large but DNS/connect are small, the time is being spent in your application code.
Why is my TTFB different from other tools?
Location matters most: a round trip from our server region to yours may differ from a visitor's. Tools also differ in whether they count redirects and connection setup, and whether they reuse warm connections. Compare trends with the same tool rather than absolute numbers across tools.