To make newly deployed JavaScript bundles available promptly, give each changed bundle a new content-hashed URL and cache that URL for a long time. Keep the HTML entry point or deployment manifest that points to the bundle revalidatable, so a new page load discovers the new filename. Use a targeted CDN purge when a URL must stay the same or a specific cache problem needs correction.
Why a new URL is the reliable default
CDNs and browsers cache responses against a URL or cache key. If a deployment replaces the bytes at an existing JavaScript URL, a cache may continue returning the older response until it expires or is refreshed. A content-derived filename such as app.8d1f…js gives changed bytes a distinct URL, so clients requesting the new version do not have to wait for the old URL’s cached object to expire. Fastly describes publishing updated content at a new URL as an effective versioning method in its versioned URLs documentation; CloudFront also recommends a version identifier in a filename or directory in its guidance on updating existing objects.
As an Amazon Associate I earn from qualifying purchases.
This approach depends on one rule: never serve different bytes from a URL that is supposed to be immutable. If a build changes, its content hash must change too. The HTML or manifest that names the bundle is different: it needs to be checked again so clients learn the new URL.
Set cache headers by resource role
| Resource | Example policy | Why |
|---|---|---|
| Content-hashed JavaScript bundle | Cache-Control: public, max-age=31536000, immutable |
A long freshness lifetime is appropriate when the URL will never be reused for different bytes. MDN documents immutable and long-lived caching for versioned assets in its Cache-Control reference. The one-year value is an example, not a universal requirement. |
| HTML entry point or mutable deployment manifest | Cache-Control: no-cache |
Clients can store the response, but must validate it before reusing it. That lets a fresh entry document point to the current bundle rather than remaining pinned to an old filename. |
Choose the asset lifetime and old-file retention to match your rollback and deployment needs. In particular, a long-lived bundle policy is safe only when content changes produce new URLs.
Deploy in an order that keeps both versions usable
- Build fingerprinted bundles. Configure the bundler or build process to put a content hash in each JavaScript filename, and verify that changing bundle content changes that filename.
- Upload the new bundles first. Make the new hashed URLs available at the origin and through the CDN before changing the entry document.
- Publish the HTML or manifest next. The updated entry document should reference the new bundle URL and use a revalidatable policy such as
no-cache. - Keep prior hashed bundles available through the transition. A client may still hold an older HTML document and request the old bundle; retaining it also supports rollback.
This sequence follows from the versioned-URL model: old entry documents can continue naming old assets while new ones point to new assets. The cited vendor documentation establishes the URL-versioning approach; it does not prescribe a universal retention period or guarantee a particular deployment sequence.
When to purge or invalidate instead
Use a purge when you must refresh a resource at the same URL, or when a specific cached response needs correction. First make sure the origin serves the intended bytes, then purge the narrowest URL or selector that addresses the problem. Cloudflare warns that purging before updating or removing the old origin content can allow that old response to be cached again; see its cache purge guidance.
Do not treat purge and invalidation as interchangeable promises of immediate replacement. Cloudflare’s cache invalidation documentation describes marking content stale so it can be revalidated on a later request. Validators such as ETag or Last-Modified can affect that process, and stale content may be served during revalidation or origin failure under documented conditions. If stale bytes are unacceptable, check the provider’s current controls and stale-serving settings rather than assuming invalidation prevents them.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →| Approach | Best fit | Trade-off to check |
|---|---|---|
| New content-hashed URL | Static assets whose URL can change when bytes change | Keep old URLs available while clients may still reference them; update the entry HTML or manifest so new loads discover the new URL. |
| Purge or invalidation | A URL must remain unchanged, or a particular existing cache entry needs correction | Provider behavior and targeting vary. Consider browser caches as well as CDN caches, and whether stale serving during revalidation or origin trouble is acceptable. |
Verify the origin and CDN separately
After deployment or cache action, compare the response from the origin with the response delivered through the CDN. Check the status, content type, response body or digest, Cache-Control, and provider-specific cache-status headers. This distinguishes an incorrect origin response from an edge cache that has not refreshed.
For Cloudflare, check the asset request’s CF-Cache-Status after purging; its documentation notes that a successful purge API response confirms receipt of the request, not by itself that the intended content is now being delivered. Google Cloud CDN likewise advises ensuring the backend serves the intended content before invalidating, and warns that overly broad invalidations can cause a sudden request spike to an origin or bucket. See Cloudflare’s purge guidance and Google Cloud CDN’s invalidation guidance.
Diagnose common stale-asset problems
A new deployment still runs the old JavaScript
- Check which bundle URL the current HTML or manifest names. If it still points to the old filename, make sure the entry document itself is revalidated.
- If the document points to the new hashed URL, inspect whether a service worker or application-managed cache is returning a response. Service workers can implement custom cache behavior, as described in MDN’s Cache-Control reference.
Old content returns after a purge
Check the origin before repeating the purge. If it still serves the old representation at that URL, a subsequent request may refill the CDN cache with the same old bytes.
Rank #4
New HTML points to a missing bundle
Check that the new bundle was uploaded and is reachable before publishing the HTML or manifest that refers to it. Keep the previous bundle available while older entry documents may still request it.
CDN behavior differs from expectations
Do not assume that a JavaScript extension alone determines caching. Cloudflare notes that static JavaScript can be cacheable by default, but actual behavior also depends on file extension, query strings, origin headers, and cache rules. Inspect the active cache key and response headers for the specific distribution in its default cache behavior documentation.
Quick Recap
Best Value
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.
