Reduce initial server response time (slow TTFB)

What’s actually happening

Lighthouse / PageSpeed Insights lists “Reduce initial server response time” under Opportunities with the root-document time in milliseconds. Because the browser can’t start parsing or paint anything until that first byte lands, a slow TTFB drags FCP and LCP out with it. The waterfall shows a long green “Waiting (TTFB)” bar on the very first request before any other asset loads.

Common causes

• No page/full-page cache — the backend rebuilds the HTML from scratch (and re-runs DB queries) on every request.
• Slow or unindexed database queries, or N+1 queries, blocking the response while the page is assembled.
• Origin server is geographically far from the user and there’s no CDN edge caching the document.
• Underpowered or saturated hosting (shared host, cold serverless function, swapping VM), plus heavy synchronous work in the request path.
• Render-blocking third-party calls made server-side during the request (external APIs, slow upstreams).

How to fix it

1. Measure server time in isolation firstStrip the network out: curl -w 'ttfb=%{time_starttransfer}s total=%{time_total}s\n' -o /dev/null -s https://example.com from a box near your server. If time_starttransfer is already high, the backend is the problem, not the client connection. Note Lighthouse’s bar is 600ms; Core Web Vitals “good” TTFB is 800ms — aim under 600 to clear the audit.
2. Cache the rendered HTMLPut a full-page cache in front of the app — Varnish, nginx fastcgi_cache, WP Super Cache/W3TC for WordPress, or your framework’s SSR/ISR cache. The biggest single win is usually serving a cached document instead of rebuilding it per request.
3. Fix the slow queriesProfile the request (Django Debug Toolbar, Laravel Telescope, New Relic, or the framework’s query log). Add indexes for the queries hit on the main page, collapse N+1 patterns with eager loading, and cache expensive computed values in Redis/Memcached.
4. Serve the document from a CDN edgeFront the origin with Cloudflare/Fastly/CloudFront and cache the HTML at the edge (even a short TTL for logged-out pages helps). This cuts the round-trip distance, which is often half of a far-origin TTFB.
5. Right-size and warm the backendMove off oversold shared hosting if CPU is the bottleneck, keep serverless functions warm to kill cold starts, and push slow third-party/API work out of the request into a background job or a client-side fetch after first paint.