Reduce Server Response Times (TTFB): How to Fix It

What "Reduce server response times (TTFB)" actually flags

This check measures Time to First Byte, the gap between the browser asking for your page and the first byte of the response arriving. It is pure server think time: DNS, connection setup, and above all how long your backend takes to build the HTML. Google's guidance puts a good TTFB under 0.8 seconds; Lighthouse flags anything meaningfully slower. A sluggish TTFB is a tax on everything downstream, because the browser cannot start parsing, painting, or loading a single other asset until that first byte lands.

The stakes: TTFB is the floor under Largest Contentful Paint (LCP). If the server sits idle for a second before responding, your LCP can never beat a second, no matter how well the rest of the page is optimized. Slow responses also drag down crawl rate.

A real failing example (and the fix)

The most common cause on dynamic sites is a page that runs uncached database work on every request. Here a homepage builds itself fresh for every visitor:

// Every request hits the DB, renders the template, then responds.
// Under load, TTFB climbs from 200ms to 2s+.
$posts   = $db->query("SELECT * FROM posts ORDER BY date DESC LIMIT 20");
$widgets = $db->query("SELECT * FROM widgets");   // repeated per request
echo render_template($posts, $widgets);

The fix is to stop doing that work on the hot path. Cache the rendered output (full-page cache) so most requests never touch PHP or the database at all, and serve it from memory or the edge:

// Serve a cached copy when it exists; only build on a miss.
$key  = 'home:v3';
$html = $cache->get($key);          // memory/object cache
if ($html === false) {
    $posts   = $db->query("SELECT * FROM posts ORDER BY date DESC LIMIT 20");
    $widgets = $db->query("SELECT * FROM widgets");
    $html    = render_template($posts, $widgets);
    $cache->set($key, $html, 300);  // cache 5 minutes
}
echo $html;

Better still, let a full-page cache or a CDN answer the request before it ever reaches your origin:

# Tell the CDN/edge it may cache this HTML briefly
Cache-Control: public, max-age=0, s-maxage=300, stale-while-revalidate=60

Where the milliseconds go

How to detect it on your own site

1. PageSpeed Insights: the "Reduce initial server response time" audit at pagespeed.web.dev reports your measured TTFB and flags it against the 0.8s bar, using real-world field data where available.
2. Lighthouse: the same "Initial server response time" audit runs in DevTools, giving you a repeatable lab number to test fixes against.
3. DevTools Network panel: click the document request, open Timing, and read "Waiting for server response" (TTFB). Compare cold vs. warm loads to see if caching is doing its job.
4. WebPageTest: the first row of the waterfall breaks TTFB into DNS, connect, TLS, and "Time to First Byte," so you can tell a slow backend from slow connection setup, and test from multiple locations to expose distance problems.

How to fix it, step by step

1. Measure a cold and a warm TTFB so you know your baseline and whether caching engages.
2. Add full-page caching so repeat requests skip application code entirely; add object caching for the dynamic bits that remain.
3. Profile the slow requests and fix the database, add indexes, kill N+1 query loops, cache expensive lookups. See server response time optimization.
4. Put a CDN with edge caching in front so cacheable HTML is served near the user, not from a distant origin.
5. Cache or make asynchronous any blocking third-party API call in the request path.
6. If the baseline is still high on a warm cache, the host itself is the bottleneck, upgrade or tune the stack (PHP version, opcache, memory).

FAQ

What is a good TTFB number?

Google treats under 0.8 seconds as good and flags noticeably higher. Fast sites often land well under 200ms on a warm cache. Treat 0.8s as the line you should be comfortably beneath, not a goal to just barely clear.

Is TTFB a Core Web Vital?

No, TTFB is a diagnostic metric, not one of the three Core Web Vitals. But it feeds straight into LCP, so a bad TTFB quietly fails you on a metric that is counted. See the TTFB too slow guide for the connection.

Will a CDN alone fix slow TTFB?

Only if the CDN actually caches your HTML. If every request still falls through to a slow origin, the CDN just adds a hop. The win comes from serving cached responses at the edge; an uncacheable dynamic page needs the backend fixed too.

My TTFB is fine locally but slow for real users. Why?

Usually distance and load. Test from multiple WebPageTest locations, faraway users pay for the round trip to a single origin, which edge caching solves, and check whether TTFB degrades under concurrent traffic, which points at missing caching or an undersized host.

Does slow TTFB affect crawling?

Yes. Persistently slow responses can lower how aggressively Google crawls you, and outright timeouts read as 5xx server errors. Keeping TTFB low protects both speed and crawl budget.