What Is TTFB? How to Measure and Improve Time to First Byte
Time to First Byte (TTFB) is the time between a browser requesting a page and receiving the first byte of the response. It includes DNS lookup, the TCP and TLS handshakes, any redirects, and the time your server spends generating the response. Everything else a visitor sees — first paint, the largest image, interactivity — has to wait for it.
What is a good TTFB?
Google's web.dev guidance says most sites should aim for a TTFB of 0.8 seconds or less, and treats anything over 1.8 seconds as poor. TTFB is not one of the three Core Web Vitals (those are Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift), but a slow TTFB makes a good LCP very hard to achieve, because LCP cannot start until the HTML arrives.
| TTFB | Rating (web.dev) |
|---|---|
| ≤ 0.8 s | Good |
| 0.8 – 1.8 s | Needs improvement |
| > 1.8 s | Poor |
How to measure TTFB
From the command line
curl can print each phase of a request:
curl -o /dev/null -s -w "dns: %{time_namelookup}s\nconnect: %{time_connect}s\ntls: %{time_appconnect}s\nttfb: %{time_starttransfer}s\ntotal: %{time_total}s\n" https://example.comRun it several times; the first request is often slower because of cold caches and DNS.
In the browser
Open Chrome DevTools → Network, reload, click the document request and open the Timing tab. "Waiting for server response" is the server portion of TTFB.
With a crawler
The BriefCraft SEO checker measures response time from our servers along with SSL, metadata and broken links, which is useful for spotting a slow origin before launch.
What makes TTFB slow
- Server work: slow database queries, uncached rendering, cold starts on serverless functions.
- Distance: a single server far from the visitor adds round trips for TCP and TLS.
- Redirect chains:
http → https → www → /en/means several round trips before the real request. - No caching: every visitor triggers a full render for a page that rarely changes.
Fixes that make the biggest difference
- Cache full pages that are the same for every visitor (marketing pages, docs, blog). Serve them from a CDN edge.
- Use a CDN so the TLS handshake happens close to the visitor.
- Collapse redirects to a single hop, and link directly to final URLs.
- Profile the slowest endpoint and fix the query or computation behind it.
- Keep serverless functions warm or move high-traffic pages to static generation.
Expecting a traffic spike from a launch? Measure TTFB on your homepage and pricing page a few days before, then again under load. Our pre-launch checklist covers the rest.