TTFB — Server Response

Slow TTFB —
Missing Caching Headers

Every page is being served fresh from the server. Every single time.

Where to find it: Chrome DevTools > Network Panel > Response Headers > Cache-Control > Max-Age Value

What It Is

HTTP caching headers tell browsers, CDNs, and intermediate proxies how long they can store a resource before requesting a fresh copy. When these headers are missing or misconfigured, every single request for every resource — images, CSS, JavaScript, fonts — goes back to the origin server. There's no browser cache, no CDN edge cache, no intermediate storage. Every visitor, on every page load, downloads everything from scratch from the origin server. This inflates TTFB for returning visitors and eliminates the performance benefits of CDN infrastructure.

Why It Matters

Properly configured caching headers can reduce page load times for returning visitors by 50–90% and cut origin server load by eliminating redundant requests. For sites with CDNs, missing cache headers prevent the CDN from doing its job — every request bypasses the edge cache and hits the origin. For clients on managed hosting with bandwidth costs, missing cache headers also directly increase hosting bills. This is a frequently overlooked fix that delivers significant, measurable improvements in real-user field data.

Root Diagnostics

Common Causes

Understanding why this failure occurs is the first step to fixing it permanently.

No Cache-Control Headers

The server returns responses without Cache-Control headers, so browsers and CDNs default to no caching or short-lived caching. Every asset must be re-downloaded on each page visit.

Cache-Control: no-store or no-cache on Static Assets

Static assets (images, fonts, CSS) are configured with no-store or no-cache directives — often copied from API endpoint configurations. Static assets should be cached aggressively; only dynamic content needs no-cache.

Short max-age Values

Cache-Control headers exist but with max-age values of seconds or minutes rather than days or years. A max-age of 3600 (1 hour) means browsers re-download assets on every new browsing session.

CDN Not Configured to Cache HTML

The CDN is set up but configured to pass all requests through to the origin without caching HTML pages. Static assets are cached but the HTML document — which triggers all other requests — is not.

Interactive Standard Operating Procedure

The Fix Blueprint (Interactive SOP)

Check off each step to monitor your implementation progress live!

Implementation Progress: 0% Completed (0/7)

1. Audit Current Cache Headers

Open Chrome DevTools, go to the Network tab, and inspect the response headers for key assets: CSS files, JS files, images, fonts, and the HTML document. Check for Cache-Control, Expires, and ETag headers on each. Document what's present and what's missing.

2. Set Long max-age for Versioned Static Assets

For CSS, JavaScript, and image files that have cache-busting in their filenames (e.g., style.abc123.css), set Cache-Control: public, max-age=31536000, immutable — a full year. These files get new names on each deploy, so long caching is safe.

3. Configure Cache-Control for HTML Pages

For HTML documents, set Cache-Control: no-cache (not no-store). This tells browsers to always check for a fresh version but use the cached copy if the server confirms nothing has changed — reducing bandwidth while keeping content fresh.

4. Add ETag Headers

Enable ETag headers on the server. ETags allow conditional requests — the browser sends the ETag with its request, and if the resource hasn't changed, the server returns a 304 Not Modified response instead of the full resource, eliminating download time.

5. Configure CDN Cache Rules

In your CDN (Cloudflare, Fastly, CloudFront), set up explicit cache rules: cache static assets for 1 year, cache HTML for 1–24 hours depending on update frequency. Confirm the CDN is returning HIT responses (not MISS or BYPASS) for repeat requests.

6. Implement Cache-Busting for Deployments

Add version hashes to asset filenames in your build process so that when assets change, the filename changes and the cache is automatically busted. This enables aggressive long-term caching without serving stale assets after updates.

7. Validate with WebPageTest

Run a Repeat View test in WebPageTest. On the first view, assets are downloaded; on the repeat view, they should be served from cache. Compare first-view vs repeat-view load times — a well-cached site should be 50–80% faster on repeat view.

Tools

Chrome DevTools Network Panel
Free | Inspect response headers on any asset to check Cache-Control, Expires, and ETag values
WebPageTest
Free (webpagetest.org) | Repeat View test shows exactly which assets are cached and which are re-downloaded on return visits
GTmetrix
Free tier available | Caching report flags all assets missing or misconfigured cache headers with specific fix recommendations

Time to Fix

30–60 minutes

To audit headers across all asset types

Hours

Server config + CDN rules implementation

Pro Tip

immutable in Cache-Control eliminates unnecessary revalidation requests.

Adding immutable to Cache-Control headers for versioned assets (Cache-Control: public, max-age=31536000, immutable) tells browsers not to bother checking whether the resource has changed during the max-age period — even on explicit reload. Without immutable, browsers still send conditional requests to the server to validate cached resources on reload. With immutable, those requests are eliminated entirely for properly fingerprinted assets.

Slow TTFB — Missing Caching Headers