Vendor Chunking

Vendor chunking separates relatively stable third-party dependencies from application code so browsers can reuse cached vendor assets across application releases. The technique can reduce repeat downloads, but its effectiveness depends on stable chunk boundaries and the caching strategy.

Vendor chunking is a bundling strategy where dependencies such as framework libraries and utility packages are placed into one or more chunks separate from frequently changing application modules. A deployment that changes application code can then leave the vendor chunk unchanged, allowing browsers to reuse it from cache.

The main benefit comes from different change frequencies. Application code may change on every release, while dependencies often remain unchanged for many releases. Separating them can therefore increase cache reuse and reduce the amount of JavaScript that returning users need to download after an application update.

A vendor chunk is not automatically better than one large bundle. Modern bundlers can perform code splitting based on the module graph, dynamic imports, and content hashes. A manually maintained vendor entry can become unnecessarily large or unstable when dependency composition changes, so the strategy should be evaluated using actual bundle and caching behavior.

Effective chunking also requires appropriate cache headers and stable filenames, commonly through content hashing. If the vendor chunk changes whenever application code changes, the browser cannot reuse it as intended. Conversely, putting too many unrelated dependencies into a shared chunk can make initial loads larger and increase the cost for users who need only a small part of the application.

Key points

• Separate stable third-party dependencies from frequently changing application code.
• The primary goal is better browser cache reuse across application releases.
• Content hashing and long-lived cache headers help make the strategy effective.
• A large vendor chunk can hurt initial-load performance if users do not need most of its contents.
• Modern code splitting can sometimes provide better boundaries than a manually maintained vendor bundle.

Interview questions

Why would you separate vendor dependencies from application code?

Third-party dependencies often change less frequently than application code. If they are placed in a separate chunk, a new application release can leave that chunk unchanged. The browser may then reuse the cached vendor file instead of downloading it again. This can reduce transferred bytes for returning users.

How does content hashing interact with vendor chunking?

A content-hashed filename changes when the contents of a chunk change. If application changes do not modify the vendor chunk, its hashed filename remains the same and the browser can reuse its cached copy. The application chunk can receive a new filename independently. This makes cache invalidation align more closely with actual content changes.

What are the trade-offs of putting all dependencies into one vendor chunk?

A single vendor chunk creates a simple cache boundary, but it can become large. Users may have to download dependencies they do not need for the initial page or route. Changes to any dependency can also invalidate the entire vendor chunk. More granular splitting can reduce these costs, but too many chunks can introduce additional requests and coordination overhead.

When might manual vendor chunking be inferior to automatic code splitting?

Manual vendor rules can impose boundaries that do not match how the application actually loads modules. Modern bundlers can analyze the dependency graph and split code around entry points and dynamic imports. A manual vendor bucket may also become unstable or oversized as dependencies evolve. I would compare the resulting chunk graph, cache reuse, and real loading metrics before choosing the strategy.