For JavaScript files whose URL changes every time their contents change, use a long cache lifetime such as Cache-Control: public, max-age=31536000, immutable. Keep the HTML document that points to those files revalidatable—typically Cache-Control: no-cache—so browsers can discover new filenames after a deployment.
Set a long lifetime only for truly versioned files
A cache identifies a response by its URL. If you publish changed JavaScript under the same URL, a browser or intermediary may keep serving the old cached response until it becomes stale. Instead, make each content change produce a new URL, commonly with a hash in the filename, such as app.8f31c2.js. See MDN’s HTTP caching guide for how versioned URLs separate cached versions.
For a static asset whose URL will never serve different contents, a typical response header is:
Cache-Control: public, max-age=31536000, immutable
max-age=31536000 is a one-year freshness interval, not a measured performance result. MDN uses it as an example in its Cache-Control reference. The immutable directive indicates that the fresh response need not be revalidated. Do not use this long-lived policy if a deployment can overwrite the contents at that same URL. For a stable URL, use a shorter freshness lifetime or require revalidation.
#1 Best Overall
What each directive does
max-age=31536000allows a stored response to be reused while fresh for one year after it is received.immutablesignals that the representation will not change while fresh; it is appropriate only when the URL-to-content mapping is enforced by deployment.publicpermits shared caches to store a response in cases where other rules might otherwise restrict it. It is commonly used for public static assets, but avoid it for personalized or authorization-sensitive responses unless shared caching is intentional.
Keep the HTML entry document revalidatable
The HTML document is different from the hashed JavaScript file: its stable URL must eventually point clients to the latest asset filename. A common policy is:
Cache-Control: no-cache
no-cache does not mean “do not store.” It allows storage but requires a cache to validate the response before reusing it. By contrast, no-store tells caches not to store the response at all. The distinction is documented in the MDN Cache-Control reference.
Rank #2
Use validators for revalidation, not as a substitute for versioning
For a stable URL such as the HTML entry document, an ETag or Last-Modified validator can make revalidation efficient. When the cached copy is stale, the client can ask whether it has changed; if it has not, the server may respond with 304 Not Modified rather than retransmitting the body. Validators do not replace changing the JavaScript URL when its contents change. MDN explains this process in its HTTP caching guide.
Deployment checks
- Configure the build or release process so every JavaScript content change produces a new filename or versioned URL.
- Set the long-lived asset policy on those versioned files. Include
publiconly when shared caching is safe for the response. - Set the HTML entry document to
Cache-Control: no-cache; addETagorLast-Modifiedwhere practical. - Check the actual response headers delivered to clients, including behavior at any CDN or managed cache. These layers can have product-specific controls and cache keys.
- If a file must be removed or corrected urgently, do not assume changing origin headers clears copies already stored in intermediate caches; purge the relevant managed cache as needed.
The underlying HTTP caching rules are specified in RFC 9111.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Quick Recap
Rank #4
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
