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

  1. Cache the HTML. A page served from a CDN cache skips your application entirely; server work drops to a few milliseconds.
  2. Remove redirects. Each hop repeats connection setup. Link to the canonical https:// URL with or without www — whichever you actually serve.
  3. 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.
  4. 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.
  5. 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.

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.