TTFB Too Slow: How to Diagnose and Fix It

What this check flags

This check fires when the Time to First Byte (TTFB) that real Chrome users experienced on your page — the field measurement collected in the Chrome User Experience Report (CrUX) — sits above Google's "good" threshold. TTFB is the time from the moment a browser asks for the page to the moment the first byte of the response comes back, and Google's own guidance treats anything at or under 0.8 seconds as good, 0.8–1.8 seconds as needing improvement, and over 1.8 seconds as poor. A slow TTFB doesn't just annoy people; it pushes back the start of everything else, so your Largest Contentful Paint has to sprint just to land inside its budget.

This is the field angle, not the lab audit. The number here comes from what actual visitors saw over a 28-day rolling window — their networks, their devices, their geography, your caching hit-and-miss rates. That's different from the Lighthouse lab check Reduce Server Response Times (TTFB), which measures a single simulated request against one origin under controlled conditions. Same metric name, two very different sources. When both light up, fix the origin work described in the lab audit; when only the field check fails, the culprit is usually distribution — a slow region, a cold cache, or a segment of users hitting an uncached path. Read both together and don't treat them as duplicates.

A real failing example

A WordPress store had a fast homepage and a dog-slow field TTFB on product pages. The lab audit passed because Lighthouse tested a warm, cached URL. The field data told the real story: logged-in and cart-holding users bypassed the full-page cache and hit PHP on every request. Here is the origin timing captured with curl against an uncached product URL:

$ curl -s -o /dev/null -w "dns:%{time_namelookup}  connect:%{time_connect}  ttfb:%{time_starttransfer}  total:%{time_total}n" 
  "https://example-store.com/product/blue-widget/?nocache=1"

dns:0.031  connect:0.084  ttfb:1.930  total:2.144

DNS and connect were fine (well under 100 ms combined). The 1.93 s TTFB was almost entirely server "think time" — PHP rebuilding the page and running uncached database queries for every cache-miss visitor. The fix was to stop punishing dynamic requests: an object cache (Redis) for the repeated queries, a fragment/ESI approach so the cart widget stayed dynamic while the rest of the page served from cache, and a CDN edge cache for anonymous traffic. Re-measured:

$ curl -s -o /dev/null -w "ttfb:%{time_starttransfer}  total:%{time_total}n" 
  "https://example-store.com/product/blue-widget/?nocache=1"

ttfb:0.412  total:0.590

Field TTFB in CrUX crossed back under 0.8 s at the 75th percentile over the following month, and LCP moved with it — because every LCP now started roughly 1.5 seconds earlier.

What actually goes into TTFB

TTFB is not one thing. It's a stack of sequential steps, and "the server is slow" is often the smallest piece. Knowing which stage owns the delay tells you where to spend effort.

If DNS, handshake, and travel are tight but the total is still high, your problem is server processing — the stage the server response times audit drills into. If processing is quick but users in one region are slow, the problem is geography, and a CDN is the lever. For the difference between what CrUX reports and what a synthetic tool reports, see Core Web Vitals: Field Data vs Lab Data.

How to detect it

1. PageSpeed Insights / CrUX. Run the URL through PageSpeed Insights and read the field data panel, not the lab score. If the origin or URL has enough traffic, you'll see a real TTFB distribution and its 75th-percentile value — that percentile is the one Google grades against.
2. curl from the command line. Use curl -w "%{time_starttransfer}" (as above) to isolate origin TTFB. Add ?nocache=1 or a unique query string to force a cache miss and expose your worst-case path — the one uncached users actually hit.
3. Screaming Frog. Crawl the site and check the Response Times column; sort descending to surface the slowest templates. Consistent slowness on one template (product, search, account) points straight at an uncached or query-heavy route.
4. Search Console + browser DevTools. The Core Web Vitals report groups URLs by field performance; open a flagged group, then use the DevTools Network panel (Waiting (TTFB) timing) on those specific URLs to confirm the origin, not the network, is the bottleneck.

How to fix it

1. Cache the full page for anonymous traffic. The single biggest win. Serve a static HTML copy to logged-out visitors so PHP/app code never runs for them.
2. Add an object cache. Redis or Memcached for repeated database queries eliminates the per-request rebuild that dominates cache-miss TTFB.
3. Put a CDN in front of the origin. Edge caching plus geographically closer POPs cuts both request travel and server load. This is what fixes a field failure that the lab test never sees.
4. Cut server processing. Profile the slow template, kill N+1 queries, add missing database indexes, and upgrade PHP/runtime versions — the concrete origin work is covered in the server response times audit.
5. Modernise the transport. HTTP/2 or HTTP/3, TLS 1.3, and connection keep-alive shave handshake overhead off every single request.

FAQ

Is TTFB officially a Core Web Vital?

No. INP, LCP, and CLS are the three Core Web Vitals. TTFB is a supporting diagnostic — Google measures it in CrUX and treats good TTFB as a prerequisite for a good LCP, but it isn't a ranking-grade Vital on its own. Fixing it is still worth it because a slow TTFB makes a good LCP nearly impossible.

Why does PageSpeed say my server is fast when this check says it's slow?

Because they measure different things. The lab/simulated score tests one warm request; this field check reports what real users — including cache-miss, mobile, and far-away visitors — actually experienced. A warm-cache lab pass hiding a cold-cache field failure is one of the most common patterns in the wild.

What TTFB should I aim for?

Under 0.8 seconds at the 75th percentile in field data. Getting well below that (200–400 ms) gives your LCP breathing room, since everything downstream can only start after the first byte lands.

Does a CDN always fix slow TTFB?

Only when the delay is network distance or origin load. If your app spends 1.5 seconds building an uncacheable page, a CDN can't cache it and TTFB stays slow. Fix the origin processing first, then let the CDN handle distribution.

How long until CrUX reflects my fix?

CrUX uses a 28-day rolling window, so expect the field number to improve gradually over about four weeks after deploying, not overnight. Confirm the fix immediately with curl and DevTools; wait for CrUX to catch up before declaring the check passed.

Related: TTFB glossary entry · Core Web Vitals overview