TTFB (Time to First Byte)

Time to First Byte (TTFB) is the time from a user starting a navigation to the first byte of the HTML response arriving in their browser. It is not one of the Core Web Vitals — but it is the opening act of all of them, because nothing on a page can start until the HTML shows up.

Here's the uncomfortable arithmetic: LCP has a 2.5-second "good" budget, and TTFB is spent first, before a single resource downloads or a single pixel paints. A 1.5-second TTFB leaves one second for everything else — fonts, CSS, hero image, render. Google's guidance for TTFB itself: under 0.8 s is good, 0.8–1.8 s needs improvement, over 1.8 s is poor. Sites chasing a good LCP should aim at the low end of that.

What actually happens before the first byte

TTFB is an umbrella over a whole chain of steps, and the chain is where you debug. In order:

The pattern that matters: everything above "origin processing" is fixed overhead you minimize once (kill redirects, use a real CDN, enable TLS 1.3). Origin processing is the variable part — and on CMS sites it is nearly always the story. A WordPress page assembled from scratch on every request can spend a leisurely two seconds in PHP and MySQL; the same page from full-page cache leaves in 50 ms.

Measuring it honestly: two tools, thirty seconds

From your terminal, curl splits the chain apart for you:

curl -so /dev/null -w "
dns:       %{time_namelookup}s
connect:   %{time_connect}s
tls:       %{time_appconnect}s
ttfb:      %{time_starttransfer}s
redirects: %{num_redirects}
" -L https://example.com/

If ttfb is high but tls is low, the time is origin processing. If they're both high, you have a network/edge problem. In the browser, the same breakdown for real navigations:

const nav = performance.getEntriesByType('navigation')[0];
console.log({
  redirect: nav.redirectEnd - nav.redirectStart,
  dns:      nav.domainLookupEnd - nav.domainLookupStart,
  tls:      nav.connectEnd - nav.secureConnectionStart,
  ttfb:     nav.responseStart - nav.startTime
});

One warning: your curl from a desktop on fiber, hitting a warm cache, is the best case that will ever exist. Field TTFB includes users three continents away hitting cache misses on cellular. Expect the CrUX number to be substantially worse than your terminal, and trust the field number — the reasoning is the same as for every vitals metric (field vs lab data).

How to check TTFB on your own site

1. PageSpeed Insights: the field data block includes an experimental TTFB distribution from CrUX; the lab section flags "Reduce initial server response time" when the first request is slow.
2. Chrome DevTools Network panel: click the document request, open the Timing tab — "Waiting for server response" is your TTFB, split from queueing, DNS, and connection time.
3. curl with -w timing variables (above) from more than one location if you can — TTFB is geographic.
4. CrUX API: pull the origin's TTFB distribution to see the real-world spread across your audience.
5. web-vitals library: onTTFB(console.log) reports it per pageview for your own RUM, including cache-hit vs cache-miss variance you'll never see in one-off tests.

Common mistakes in TTFB audits

• Measuring once and calling it done. TTFB is bimodal on cached sites: 80 ms on a HIT, 1.9 s on a MISS. Check the cache-status response header (x-cache, cf-cache-status) on every measurement, and measure the miss path deliberately.
• Buying a CDN for uncacheable pages. If every HTML response is Cache-Control: no-store (session cookies, cart state everywhere), the CDN is a fancy pipe to your slow origin. Fix cacheability first, then the CDN pays off.
• Ignoring redirect chains. Three hops before the final URL can add a full second before "server time" even starts — and it's invisible if your test starts at the final URL. Test the URLs users and crawlers actually enter.
• Blaming hosting when the app is the problem. A 1.8 s TTFB with 40 unindexed database queries per page will follow you to more expensive hosting. Profile before you migrate.
• Optimizing TTFB last. It's the first phase of LCP; a saved second here is a second saved on every metric downstream. The remediation checklist lives in reduce server response times.

Frequently asked questions

Is TTFB a ranking factor?

Not directly — it isn't a Core Web Vital. But it's inside LCP, which is, and slow HTML delivery also throttles how efficiently Googlebot crawls large sites. Treat it as infrastructure for the metrics that do count.

What's a good TTFB target?

Google's documented bands: good under 800 ms, poor over 1800 ms, at the 75th percentile. For anything cacheable, be greedier — a CDN edge HIT should land well under 200 ms for most of your audience.

Does TTFB include redirect time?

As users and CrUX experience it, yes — measurement starts at the original navigation, so every hop is on the clock. This is why redirect-chain cleanup shows up directly in field TTFB.

Can TTFB be too fast to bother with?

If your field TTFB is already under ~500 ms at p75, your LCP problems live elsewhere — image delivery or render-blocking resources. Don't micro-optimize 80 ms while a 300 KB hero PNG walks free.

Server-side rendering made my TTFB worse — is that bad?

It's a trade: SSR spends server time to send ready-to-paint HTML, which usually wins on LCP overall versus shipping a blank shell that renders client-side. Judge the swap by LCP and INP outcomes, not by TTFB alone.