Serve Static Assets with an Efficient Cache Policy: How to Fix It

What this means

Every time a browser requests a file, the server can attach a Cache-Control header that tells the browser how long it may reuse that file from disk instead of fetching it again. The max-age directive sets that lifetime in seconds. When static assets ship with a short lifetime, no lifetime, or only a weak fallback, Lighthouse flags them under "Serve static assets with an efficient cache policy."

Per Chrome's Lighthouse documentation, the audit looks at responses whose type is a font, image, media file, script, or stylesheet, that returned HTTP 200, 203, or 206, and that do not carry an explicit no-cache directive. Anything in that set without a strong cache lifetime gets listed, along with its current cache TTL and transfer size.

Why it matters

A long cache lifetime mainly helps repeat visits and multi-page sessions. On a first visit the browser has to download everything anyway, but on the next page or the next visit it can serve unchanged logos, scripts, and fonts straight from local disk. Without a strong policy the browser re-fetches those bytes every time, which adds network round trips, delays rendering, and can drag on your Largest Contentful Paint.

This is a lab-data signal, so it surfaces in synthetic tools before real-user metrics. For how lab warnings relate to what visitors actually experience, see our guide on field versus lab data.

How it gets flagged

Lighthouse, which powers PageSpeed Insights and the engine behind SEO ProCheck, inspects the response headers of each qualifying asset and prints a table with the asset URL, its cache TTL, and its size. This is an opportunity-style diagnostic: it does not directly subtract from the performance score, but it points at wasted transfer that slows repeat loads. A clean result means every qualifying asset carries a meaningful cache lifetime.

How to fix it

Set a long max-age at the layer that serves your static files. Chrome recommends caching immutable static assets for a year or longer using Cache-Control: max-age=31536000 (31536000 seconds is one year). For files whose name includes a content hash (asset fingerprinting), add immutable so browsers skip revalidation entirely; the hash changes when the content changes, so a new request is forced automatically.

Apache (.htaccess)

<IfModule mod_headers.c>
  # Fingerprinted assets: cache for a year, never revalidate
  <FilesMatch "\.(css|js|woff2|svg|jpg|jpeg|png|gif|webp|avif)$">
    Header set Cache-Control "public, max-age=31536000, immutable"
  </FilesMatch>
</IfModule>

Nginx

location ~* \.(css|js|woff2|svg|jpg|jpeg|png|gif|webp|avif)$ {
    add_header Cache-Control "public, max-age=31536000, immutable";
}

If a CDN sits in front of your origin (Cloudflare, Fastly, CloudFront, and similar), confirm it honors or sets these headers; the edge cache, not the origin, is what most visitors actually hit. After deploying, re-run the audit to confirm the listed assets clear. If headers do not change at all, check that the server module is enabled and that no 5xx error is breaking the response chain; our note on 5xx server errors covers that case.

False positives

Not every flagged file should get a one-year lifetime. Files that genuinely change at the same URL, such as an unhashed main.css, a rotating banner, or a tracking script, must not be frozen for a year or visitors will see stale content. For those, Chrome suggests Cache-Control: no-cache, which still allows storage but makes the browser revalidate with the server before reuse. Third-party assets you do not control (analytics, ad, or widget scripts) are also commonly listed, and you cannot rewrite their headers; those are expected residual entries, not defects in your setup.

FAQ