Static asset caching

What this check looks for

Using a sample of the page's static assets collected during the performance measurement pass, this check computes what share carry a long-lived, cacheable Cache-Control header. 90% or more passes. Between 50% and 90% warns; below 50% fails. Pages with no asset sample collected report "na".

Why it matters

A static asset — a JavaScript bundle, a stylesheet, a logo image — that doesn't change between visits should be cached aggressively by the browser, so a repeat visitor's second page load skips re-downloading files they already have; without long-lived caching, every visit re-fetches the same unchanged files, wasting bandwidth and time on both sides. This matters most for returning visitors and for multi-page browsing sessions within the same site, where the cumulative savings from proper caching compound quickly. It's also a common gap in default server configurations, which frequently ship a much shorter cache lifetime (or none at all) than static, versioned assets actually need.

How to fix it

Serve static assets with a long max-age and fingerprinted (content-hashed) filenames so cache invalidation happens naturally when the file changes:

Cache-Control: public, max-age=31536000, immutable

# Fingerprinted filename so a new deploy gets a new URL, bypassing the cache safely
/assets/app.a1b2c3d4.js

Never apply a long cache lifetime to a filename that doesn't change on updates — that combination causes visitors to keep an outdated file long after you've shipped a fix.