Fix Inefficient Cache Policy (Cache-Control)

What this means

Why it matters

How to fix it

1. 1

   Split assets into immutable vs. mutable

   Sort your static files into two buckets. Fingerprinted assets, whose filenames include a content hash like main.8a3f.css, can safely use a one-year cache because any change produces a new filename. Files that keep the same URL when edited, such as a logo at /logo.png or an un-hashed stylesheet, need a shorter TTL or a revalidation strategy so users pick up updates. Never apply a long immutable cache to HTML documents; those must stay fresh.

2. 2

   Set a long immutable cache on fingerprinted files

   For hashed static files, send Cache-Control: public, max-age=31536000, immutable. That is one year in seconds, and immutable tells the browser not to revalidate even on a reload. This one header clears the audit for the vast majority of flagged JS, CSS, and font files. Confirm it is actually present by checking the Network tab or running curl -I https://yoursite.com/assets/app.8a3f.js.

3. 3

   Use revalidation for files that change at the same URL

   For assets you edit in place without renaming, use a shorter max-age, for example Cache-Control: public, max-age=3600. If you need the browser to confirm freshness on every request while still avoiding a full re-download, use no-cache instead (note: no-cache means revalidate before use, not "don't cache"). Pair either approach with a strong ETag or Last-Modified header so the server can answer with a cheap 304 Not Modified.

4. 4

   Set the header at the layer that serves the asset

   Where you set headers depends on your stack. On Apache, use .htaccess with mod_expires and mod_headers; on Nginx, use a location block with expires and add_header Cache-Control; on a CDN like Cloudflare, use a Cache Rule with an edge and browser TTL. If a CDN sits in front of your origin, its headers usually win, so set the rule there. Managed platforms like Vercel, Netlify, and Shopify already fingerprint and cache built assets automatically; see the platform notes below.

5. 5

   Re-run the audit and check repeat views

   After deploying, re-run Lighthouse or the audit. Then load a page, navigate to a second page, and watch the Network tab: cached assets should show as served "from disk cache" or "from memory cache" with no round trip. If files are still flagged, the header is likely being stripped or overridden by an upstream proxy or CDN, or it is set on the HTML document instead of the static file. Check the exact response headers on the specific URLs the audit listed.

Example

# Fingerprinted/immutable assets - cache hard for a year
location ~* \.(css|js|woff2|png|jpg|jpeg|webp|avif|svg|ico)$ {
    expires 1y;
    add_header Cache-Control "public, max-age=31536000, immutable";
}

# HTML documents - always revalidate so content stays fresh
location ~* \.html$ {
    add_header Cache-Control "no-cache";
}

Nginx: long immutable cache for versioned assets, revalidation for HTML

Platform-specific steps

Frequently asked