I ignored my bundle size for months. By the time I checked, my production build was several megabytes of JavaScript in a single file — and every deploy forced my users to download all of it again. Vendor chunking is what I wish I’d known earlier.
Let’s say you are building a project using React, and for that project you need some component library, a library to handle date-related things, or a library to handle your state. So you reach for the usual suspects — Material UI, dayjs, TanStack Query, Redux and so on.
Initially, everything will work smoothly for you as well as for your end users. But as you keep shipping new features and adding dependencies, the bundle quietly grows. Locally, you don’t notice. But in production, it’s the end users who end up paying the price. What happens behind the scenes is that, when dependencies are included in the initial bundle, they can significantly increase the JavaScript downloaded by the browser. As a result, you end up with a poor Lighthouse score, slow initial load times, and a large JavaScript bundle — all of which hurt the user experience.
Your production build looks like this:
dist/assets/index-xxxx.js → 1.2 MB
Enter fullscreen mode
Exit fullscreen mode
This is exactly the kind of problem vendor chunking is designed to solve.
What is Vendor Chunking?
Vendor chunking is a technique where you can separate the third-party dependencies from your main bundle chunk. So you will have a main chunk which will contain your main application code and a vendor chunk which will contain the third-party dependency code.
How does Vendor Chunking help with large bundle size?
When you implement vendor chunking, your application is typically split into at least two separate bundles:
Main Chunk: Contains your application code
Vendor Chunk: Contains third-party dependencies and libraries
When a user visits your website for the first time, the browser downloads both chunks and stores them in the cache. This is where caching becomes very useful.
It’s worth noting that vendor chunking doesn’t come into play on the user’s first visit, because the browser still has to fetch both the chunks. The real performance gains show up when a user revisits the website and the cached vendor chunk can be reused.
Since third-party dependencies do not change frequently, the vendor chunk usually remains the same across deployments. On the other hand, whenever you ship new features, bug fixes, or other updates, your application code changes — which results in a new main chunk being generated.
When you generate a new production build, the bundler will again create:
A new main chunk containing the updated application code
The same vendor chunk, because the dependency code has not changed
Now consider this scenario where a user’s browser has already cached both the chunks because the user has already visited your website, and you deploy a new feature to the production. As a result, the user’s browser only needs to download the new main chunk, while the cached vendor chunk can be reused. This is how vendor chunks help in improving user experience.
Vendor Chunking in Action
Now let’s understand this whole thing using the code. I have a React project where I have installed multiple dependencies such as MUI, Chart.js, Lodash, dayjs and React Router.
Before Vendor Chunking, the build will look something like this:
Note: I’ve disabled tree-shaking for this demo to keep the bundle size large and make the impact of vendor chunking more visible.
The build will contain only one JS file and the browser has to download this large ~4.6 MB file.
Now I will implement vendor chunking by adding this code block in my vite.config.ts file:
Note: I’m using Vite v8, which uses Rolldown as the bundler. If you’re on an older Vite version with Rollup, the config syntax will be different
So after this, the build will look something like this:
As you can see, now we have two JS files:
Now the browser has to download both of these files so that our application loads correctly. Here comes the crazy part. Let’s update the code and try to generate the new production build. Here’s what it will generate:
If you compare the files with the previous build, you will find that only index-xx.js changed, while vendor-xx.js stays the same, because we didn’t upgrade any package versions; we only updated the application code.Now when a user revisits our website, the browser will only fetch the new index-xx.js from the server, vendor-xx.js will be served from cache.
This is how vendor chunking helps in performance improvement for web applications.
Splitting Vendors Further
So far we have bundled all the dependencies into a single chunk. This works well for small to medium applications, but as the dependency list grows, a single vendor chunk has a drawback. If you update the version of any library, a new vendor chunk will be generated and users have to re-download the whole thing – even if 95% of the code is same.
To tackle this issue, we can split vendors into multiple chunks. For example, you can keep your UI library in one chunk, your utility libraries in another, and your charting library in a third:
The final node_modules group is a catch-all so dependencies like React land in a vendor chunk too, rather than your main bundle.
After this config, your build output will look something like this:
Note: Just don’t go overboard with splitting — too many small chunks can hurt performance due to HTTP overhead and less effective compression
Wrapping Up
Vendor chunking is one of those optimizations that costs you a few lines of config and pays you back on every deploy. The core idea is simple: your application code changes often, third-party code doesn’t — so why force your users to re-download libraries they already have?
If you haven’t audited your production bundle in a while, run a build and take a look. You might be surprised how much of it is third-party code waiting to be cached properly.
