TTFB (Time to First Byte): what it is, what's acceptable, and how to reduce server response time

The first byte is the first thing you pay for on any page load. If your server is slow to start answering, everything after it starts late: TTFB (Time to First Byte) decides when your page begins to exist.

What TTFB (Time to First Byte) is and where the time goes

TTFB measures the time between the start of the navigation and the moment the first byte of the response starts to arrive. It is calculated from startTime to responseStart in the Navigation Timing API, and the full definition lives in web.dev's Time to First Byte guide.

The most common mistake is reading it as "how long my server takes". TTFB is the sum of five parts, and only the last one depends on your backend:

• Redirects.
• Service worker startup, if one exists.
• DNS resolution.
• Connection and TLS negotiation.
• The request until the first byte: this is where server work counts.

You can have a lightning-fast backend with a bad TTFB because of DNS, redirects or TLS, and the opposite too: a slow host hidden behind an excellent network. That is why diagnosis starts by measuring the parts.

TTFB is not a Core Web Vital (but it conditions the ones that are)

The Core Web Vitals are LCP, INP and CLS. TTFB is a foundational, diagnostic metric that comes before the loading metrics, and Google says it plainly: meeting its "good" threshold is not strictly necessary, provided it does not hold back the metrics that do matter. The full framework is in what Core Web Vitals are and how they affect SEO.

"First byte" also includes 103 Early Hints

Chrome 115 changed the measurement to count the start of the final response headers and reverted it in Chrome 133 because the tools were no longer compatible. With 103 Early Hints enabled, the browser downloads critical resources before the HTML arrives, so the TTFB you see can be lower than the real work your server did: also measure it from the inside.

What's acceptable: 0.8 seconds at the 75th percentile (and why Lighthouse says 600 ms)

The official threshold: good up to 0.8 s, poor above 1.8 s, at the 75th percentile of page loads, with mobile and desktop measured separately. Respond fast so that same percentile gets a First Contentful Paint inside the good threshold, which is 1.8 s (First Contentful Paint): the 0.8 s of TTFB is the margin you leave the browser to paint.

That is where the 600 ms confusion comes from: Lighthouse's Reduce server response times audit and the "Document request latency" insight in PageSpeed Insights fail the main document above 600 ms. They do not contradict the 800 ms figure: their documentation explains that the TTFB threshold is higher because it includes DNS and redirects, while the audit only covers the final document response. And to settle the most repeated doubt: TTFB is not a direct ranking factor.

How to measure TTFB: field first, lab second

Field data comes from real users and decides whether you have a problem; lab data helps you reproduce and fix it.

Field data

• CrUX: TTFB is in BigQuery and in the CrUX API as experimental_time_to_first_byte, with a three-bucket histogram and a 75th percentile (CrUX API documentation).
• Only the main navigation request is reported; cross-origin resources need Timing-Allow-Origin.
• The API also publishes round_trip_time: useful context, not a replacement for TTFB.
• PageSpeed Insights shows field and lab data together.

Lab data

• Lighthouse: reports the main document time against a 600 ms limit and excludes DNS and redirects, so it underestimates TTFB: it is a subset of the metric.
• PSI, Document request latency insight: flags redirects and a server response above 600 ms.
• DevTools: the Network (Timings) and Performance panels show the real waterfall.

Why field and lab disagree

If the lab is worse, your test environment is more limited than the typical user's and the recommendations still hold. If the field is worse, there are things the lab cannot see: server cache, redirects and network differences. Test a rarely visited page or add a parameter that bypasses the cache to see a cold TTFB.

The data SEO cares about: Crawl Stats

The Crawl Stats report in Search Console shows the average response time for everything Googlebot downloads, plus host status. Its own help text puts it plainly: if your site is responding slowly, Googlebot throttles back its requests to avoid overloading your server. A slow server does not just feel slow, it also gets crawled less. How to read it is in how to use Google Search Console to improve your SEO, and the server side in server log analysis for SEO.

Measure from the inside: the Server-Timing header

Server-Timing: db;desc="Database";dur=121.3, ssr;desc="Server-side rendering";dur=212.2 splits TTFB across database, server-side rendering and edge cache. It shows up in DevTools and is exposed through the PerformanceServerTiming API (MDN documentation). Careful: it can expose internal infrastructure details, so do not ship it with sensitive information on a public production site.

Why your TTFB is slow: the usual suspects

• Hosting: the plan is the first variable; without memory and CPU, the instance serves every page the hard way.
• No cache: every visit regenerates the page, and the first visitor in each cache window pays the full latency.
• No CDN: if your users are far from the origin, round-trip latency is paid anyway.
• Redirect chains: http to https, with and without www, trailing slash, shorteners and campaigns.
• Slow DNS and TLS, and HTTP/1.1 where HTTP/2 or HTTP/3 is available.
• Caches and Early Hints hiding the problem: measuring a cached homepage does not represent the first visitor.

How to bring it down, highest impact first

1. Measure cold before touching anything: field data (CrUX or PSI) plus a URL without cache.
2. Review hosting and resources: instance memory and CPU, up-to-date language, database and web server versions.
3. Add page and object cache: OPcache, Redis or Memcached, and define what is not cached.
4. Serve from the edge with a CDN. Watch analytics parameters: they can stop the edge from reusing its copy.
5. Remove the redirects you control and add HSTS so the hop to https does not cost a round trip.
6. Check protocol, TLS and compression: HTTP/2 or HTTP/3, TLS 1.3, and brotli, gzip or zstd.
7. Deliver the HTML as early as possible: markup streaming, streaming SSR or static generation.
8. Use 103 Early Hints only if the backend is genuinely slow, and keep measuring server time.
9. Re-check with the same field data and wait a few weeks: field data lags.

TTFB and SEO: what actually happens

What does happen is that TTFB stretches LCP, because the LCP clock starts at navigation and TTFB is its first part: the full breakdown is in how to measure and improve LCP.

The second effect is documented and it is about crawling: Google raises the crawl capacity limit when response times (latency and Time-to-First Byte included) hold steady or improve, and lowers it when the site gets slower or returns 5xx and 429 responses (managing your crawl budget).

The honest sentence, with no promises: improving TTFB is not a trick to climb positions, it removes a ceiling that limits what you can actually improve and keeps you from losing crawl.

Common mistakes when optimizing TTFB

• Chasing a target Google never published: repeating "TTFB under 200 ms" with no source. The documented number is 0.8 s at the 75th percentile.
• Believing Lighthouse measures the full TTFB: it excludes DNS and redirects.
• Measuring only the cached homepage or without splitting mobile and desktop.
• Fixing the frontend when the server is the problem.
• Caching HTML with personalized content and breaking the experience to save a few hundred milliseconds.
• Forgetting the first visit: a warm-cache TTFB does not represent the first visitor.

Conclusion: the six-step checklist

1. Look at the 75th percentile in field data, mobile and desktop separately.
2. If the field is worse than the lab, look at cache, redirects and network with a cold URL.
3. Remove redirects and use HSTS for the hop to HTTPS.
4. Add page and object cache and, if your users are far away, a CDN.
5. Check protocol, TLS and compression.
6. Review Crawl Stats in Search Console: average response time and host status.