EngineeringScorePerformance 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.
Why 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.