Build assets are served without caching
A hashed, build-immutable asset (its filename changes when its contents change) is served with no long-lived Cache-Control, so a returning visitor re-downloads it every time instead of reading it from cache.
Why it matters
A hashed, build-immutable asset (its filename changes when its contents change) is served with no long-lived Cache-Control, so a returning visitor re-downloads it every time instead of reading it from cache. Because the filename is already cache-busting, it is safe to cache these forever: send `Cache-Control: public, max-age=31536000, immutable` for hashed assets. (The asset checked is in the evidence.)
How ShipReady detects it
Transport hygiene: how the origin sends its bytes. Origin-scoped because these are facts about the server, not a document — and each is read with a header- only stream fetch, so the body is never downloaded.
Detection is deterministic. ShipReady reports this only when it observes the condition directly, and prefers to miss a real problem over inventing one. Rule version 1.0.0.
How to fix it
This is the prompt ShipReady puts in your report — written to be pasted straight into Cursor, Claude Code, or whichever assistant built the app.
A build-immutable asset — a JS/CSS file with a content hash in its name — is served without a long-lived Cache-Control, so returning visitors re-download it every time instead of reusing their cache. Because the filename changes whenever the contents change, these are safe to cache permanently: serve hashed assets with `Cache-Control: public, max-age=31536000, immutable`. Set this at your CDN or static host (most set it automatically for a build output directory), or in your framework's asset config. Keep your HTML on a short or no-cache policy — only the hashed static assets get the long max-age.
Frequently asked questions
- What does "Build assets are served without caching" mean?
- A hashed, build-immutable asset (its filename changes when its contents change) is served with no long-lived Cache-Control, so a returning visitor re-downloads it every time instead of reading it from cache.
- How serious is it?
- ShipReady rates this low. Worth fixing. Small individually, and they accumulate.
- How do I fix it?
- Paste the fix prompt on this page into Cursor, Claude Code or your AI editor. It is the same prompt ShipReady puts in your report.
- Can I check my own site?
- Yes — ShipReady scans up to ten pages of any public site for free and reports this alongside every other check. The free report lists every issue it finds and shows full evidence and a fix prompt for the critical and high-severity ones; medium and low findings are counted and unlock on Pro.
Related checks
- The page is served without compressionmedium
- The page is reached through a chain of redirectslow
- A JavaScript bundle is large enough to make the page feel slowmedium
- An image is large enough to be slowing the page downmedium
- Real visitors wait too long to see your main contentmedium
- The page is slow to respond when people tap or clickmedium
Run this check on your site
ShipReady checks this and 193 other things across up to ten pages of your site, with an AI-ready fix for each. Free, no signup.