Chunk Naming and Cache Busting

Content-based chunk naming gives each build artifact a filename derived from its contents, allowing browsers to reuse unchanged assets while automatically requesting changed ones. It is a core deployment technique for efficient frontend caching.

Modern frontend builds split application code into chunks and typically emit JavaScript and CSS as static assets. If a filename stays identical across deployments, a browser or CDN may reuse its cached copy instead of downloading the asset again.

With content hashing, the emitted filename includes a hash derived from the asset contents, such as `app.8f31c2.js`. When the contents change, the hash changes and therefore the URL changes. When the contents remain the same, the URL can remain stable across deployments.

This enables long-lived caching for immutable assets. A deployment can serve hashed files with aggressive cache lifetimes because a changed file receives a different URL rather than overwriting the bytes associated with the old URL.

The HTML entry point generally needs a shorter cache lifetime because it contains references to the current chunk filenames. A deployment must also ensure that old chunks remain available long enough for clients using an older HTML document to finish loading them.

Chunk naming and cache busting are therefore connected to both bundler configuration and deployment strategy. Hashing alone does not solve stale HTML, missing old chunks, or poorly split dependencies.

Key points

• Hash filenames from content so changed bytes produce changed URLs.
• Unchanged chunks can retain their URLs and browser/CDN cache entries.
• Cache HTML more conservatively because it points to the current asset names.
• Keep previous hashed assets available during deployment transitions.
• Stable chunk boundaries improve cache reuse between releases.

Interview questions

Why does content hashing improve frontend caching?

A browser caches resources by URL, so an unchanged URL can reuse an existing cached response. With content hashing, the URL incorporates information derived from the asset contents. If the asset changes, its URL changes and the browser requests the new file. If it does not change, the old URL can remain cached and does not need to be downloaded again.

What should be cached aggressively and what should be cached conservatively in a hashed build?

Hashed JavaScript, CSS, and other immutable assets can generally receive long cache lifetimes because a content change produces a new URL. The HTML entry point should usually be cached more cautiously because it references the current asset filenames. Static assets from older builds may also need to remain available during deployment transitions. This combination lets clients discover new versions without sacrificing cache efficiency for unchanged resources.

How can a deployment break users even when every JavaScript file has a content hash?

Suppose a user has an older HTML document that references an older hashed chunk. If the deployment removes that old chunk immediately, the browser can receive a 404 when it tries to load it. This can happen during a rolling deployment or when users retain an old page for a long time. Keeping previous assets available, often for a retention period, reduces this failure mode.

Why can changing a small source file invalidate more than one chunk?

The relationship between source modules and emitted chunks depends on the bundler's dependency graph and chunking strategy. A change can propagate into a shared chunk or alter generated module content, causing the hash of that chunk to change. Poorly chosen boundaries can therefore reduce cache reuse even when most application behavior is unchanged. Good chunking separates frequently changing application code from relatively stable dependencies where practical.

What role does a service worker play in cache-busting strategy?

A service worker can introduce an additional caching layer whose behavior is independent of ordinary browser HTTP caching. Even correctly hashed URLs can appear stale if the service worker serves an older precached manifest or asset set. The update lifecycle therefore needs to be designed alongside the application's deployment strategy. A robust system defines how new workers activate, how old clients are handled, and how cached assets are retired.