What is TTFB?

TTFB (time to first byte) is the time from the start of a request until the first byte of the response arrives. For a page load it includes redirects, the DNS lookup, the TCP and TLS handshakes and server processing time. web.dev considers 0.8 seconds or less good for most sites, measured at the 75th percentile.

Updated · by PuzariCloud · also called time to first byte

Why TTFB matters

Nothing can render before the first byte arrives, so TTFB is a floor under LCP and every other loading metric. A slow TTFB usually points at the server (slow queries, no caching) or at the network path (no CDN, a distant region, redirect chains).

Because it bundles several phases, the number alone does not say what to fix. Splitting it into its parts does.

How to measure TTFB

TTFB ≈ redirects + DNS lookup + TCP connect + TLS handshake + waiting for the server's first byte

Worked example

A page load on a fresh connection: DNS lookup 20 ms, TCP connect 30 ms, TLS handshake 45 ms, then 260 ms until the first byte of the HTML arrives. There are no redirects.

  1. TTFB = 0 + 20 + 30 + 45 + 260 = 355 ms.
  2. 355 ms is well within the 800 ms guidance.
  3. 260 of the 355 ms (73%) is waiting for the server, so caching or faster queries would help this page more than a CDN.

Result: For a page where most of TTFB is network (DNS, connect, TLS), the answer would be the opposite: serve it closer to users.

Common mistakes

  • Measuring only from your office. TTFB depends on distance. Measure from where users are, or with RUM.
  • Warm connections only. Repeat requests reuse connections and skip DNS, TCP and TLS. Measure cold loads too.
  • Chasing TTFB on CDN cache hits. If the CDN serves from cache, TTFB is mostly network. Look at cache misses.
  • Redirect chains. http to https to www adds a full round trip per hop.

How Vigil handles TTFB

  • Uptime checks record the response time of every check and chart p50 and p95; the free HTTP request tester and uptime checker time a single request without an account.
  • Real user monitoring reports TTFB at p75 next to LCP, INP, CLS and FCP, from real visitors.
  • APM shows the server's side of it: which endpoint, query or outbound call made the server slow to send its first byte.

TTFB (time to first byte): frequently asked questions

What is a good TTFB?

web.dev's guidance is 0.8 seconds or less at the 75th percentile for most sites. Server-rendered pages with heavy queries tend to be slower than static pages served from a CDN.

Is TTFB a Core Web Vital?

No. It is a supporting metric that helps diagnose Largest Contentful Paint, which is a Core Web Vital.

How do I measure TTFB with curl?

curl -o /dev/null -s -w '%{time_starttransfer}\n' https://example.com/ prints the time to first byte in seconds, including DNS, connect and TLS.

Related terms

p95 latencyThe response time that 95% of requests beat; the slowest 5% are slower. Real user monitoring (RUM)Measuring performance and errors in your real visitors' browsers. APM (application performance monitoring)Measuring how fast and how reliably your code serves requests, down to queries and outbound calls. DNS propagationThe delay before resolvers everywhere see a changed DNS record, set by the old record's TTL.
See also: Free HTTP request tester · How to monitor Nginx · How to monitor Next.js
← TLS certificate expiry · All terms A–Z · Uptime →
Vigil by PuzariCloud

Measure it instead of estimating it

Uptime and API checks, heartbeats, status pages, on-call, traces, errors, logs and real user monitoring in one place, with every feature on every plan, including Free.

Start monitoring free Create a monitor