Static files are cached briefly or not at all

Why it matters

A file can be reused from the browser's cache while its cached response remains fresh, avoiding another download. Lighthouse has long checked cache lifetime; since Lighthouse 13 it is part of its use-cache-insight, which replaced the uses-long-cache-ttl audit.

What to do

1. Look at the finding: it shows the file, its Cache-Control or Expires, the lifetime we worked out and the pages that use it.
2. For files whose name or address changes with each version, send a long lifetime, such as Cache-Control: max-age=31536000, a year.
3. For other files, send some lifetime, or add a version to their address so that a long one is safe; files from other companies can only be changed by them.

When to leave it as it is: if the file belongs to another company, or must be fresh on every request, you can leave it.

What we read

We read the captured responses of scripts, stylesheets, images and fonts referenced by audited pages and work out their declared lifetime from Cache-Control, or else from Expires. Resource collection follows the run's recorded policy and safety bounds; a file without sufficient captured evidence remains unchecked. no-store, a bare no-cache, a zero lifetime and no policy at all count as none; an invalid max-age is left unjudged, while an invalid Expires date counts as zero; s-maxage is ignored.

A file is reported when it has no lifetime, or when it is versioned and its lifetime is under the setting, 30 days by default, recorded with each audit. A file counts as versioned when its name has a hexadecimal token of 8 to 64 characters, such as app.3f9a2c1b.js, or its address has a v, ver, version, rev or hash parameter. Files from other sites are included.

A file is not judged when its type or policy is unclear, for example Cache-Control: public with no lifetime, and a page is marked as not checked when its HTML could not be read in full, for example because it contains unsupported SVG markup, <select> or <math> or a file it declares was not among those fetched.

Example & evidence

Illustrative example — one file's cache header, not a live audit.

https://bakery.example/css/site.3f9a2c1b.css, used on 42 pages, was sent with:

Cache-Control: max-age=3600

The name carries a version, and one hour is shorter than 30 days, so the file is reported with the pages that use it.

Cache-Control: max-age=31536000, immutable

A possible correction: a year, since a new version gets a new name.

Confirm & check again

Check for yourself: open your browser's developer tools on the Network tab, click a file and read its Cache-Control header.

Check again: Full audit — Run a new site audit. Confirming a fix requires sufficient current evidence for the same file and its referring pages, with a cache lifetime that no longer meets the finding condition. Lowering the recorded minimum can remove a short-lifetime finding for a versioned file, but it does not clear a zero or missing lifetime. Missing or incomplete evidence cannot confirm a fix.

Limits & sources

It is one response per file to our crawler, and only the declared lifetime counts, not Age, immutable, CDN copies or service workers. Versioning is recognised from a hexadecimal filename token or from a supported v, ver, version, rev or hash query parameter; other version schemes are not recognised. Repeat visits are not measured.

Confidence: High because the lifetime is worked out directly from the file's headers.

Sources

• Chrome for Developers, Lighthouse is moving to performance insight audits — lists the use-cache insight as the replacement for Lighthouse's uses-long-cache-ttl audit. Checked 28 September 2026.

Editorial review: 1 November 2026

Related

• Pages carry no cache validators — the pages themselves carry no ETag or Last-Modified.