Performance Small
Add cache-control headers to static assets
Cache-Control headers tell a returning visitor's browser (and any CDN in between) how long a static asset can be reused without re-downloading it. Without them, every visit, even a second visit five minutes later, re-fetches the same images, scripts, and stylesheets from scratch, wasting bandwidth and slowing the page down for no reason.
Find out whether your site has this problem, and every other check, in one free scan.
Check your site freeWhy it matters
Without cache headers, returning visitors re-download the same images, scripts, and stylesheets on every visit, wasting bandwidth and slowing repeat page loads unnecessarily.
How to fix
- 1 Set long max-age Cache-Control headers on versioned/hashed static assets.
- 2 Use cache-busting filenames so updates still reach users promptly.
Common mistakes
- Setting a long max-age on assets that are not cache-busted by filename, so users get stuck on a stale version after a deploy until the cache expires.
- Applying a short or no-cache policy to genuinely static, versioned assets (like hashed JS bundles) that never change once built.
- Forgetting that HTML documents usually should NOT be cached long-term the same way static assets are, since that can serve stale pages.
How to verify
- 1 Inspect the Cache-Control header on static assets and confirm a long max-age (e.g. one year) is set for versioned/hashed files.
- 2 Reload the page and confirm in devtools network panel that static assets are served from disk/memory cache, not re-downloaded.
- 3 Deploy a change to a cached asset and confirm the cache-busted filename correctly forces a fresh download.
Related checks
Ready to see where you stand?
Scan your site and get your Engineering Score with a prioritized roadmap in under a minute, no signup required.