Using Webpack Bundle Analyzer to Identify your Bundle Bloat

I work on a project that consists of one main application, a shared component library, a shared “core” library, and (currently) 5 sub-applications.

Needless to say, it has a bad case of bundle bloat, and I don’t think it’s alone. As a result of relying on webpack to bundle our applications as a single chunk (I’m not complaining, ES6 modules are a thing of beauty that I believe any experienced JS developer can attest to), our bundle surpassed 16MB. This caused an initial load time of over 10 seconds, and a white screen displayed to the user for that time.

Obviously, a single bundle is ok for small apps, and webpack makes it easy to bundle chunk. We weren’t utilizing webpack to its fullest. But, at the same time, there are steps that you can take to shrink your application’s footprint that helps eliminate some of that size. Bundle chunking is just a duct-tape solution to a fat bundle.

Enter: webpack-bundle-analyzer. This NPM module is an awesome blessing. It helped me visualize where our problems were. Why is all of Ramda being imported, when we only use 10 functions? Moment has how many locales?!

Not only does it highlight mistakes, but it also helps remedy them. Utilizing the analyzer, I began working on bundle chunking our application. As I made changes based on recommendations from the interwebs, I could see how it impacted our build. What if I changed the minChunks property of our CommonsChunkPlugin from 2 to 3? What if I create a vendor chunk?

The result of running the webpack-bundle-analyzer

Don’t get me wrong, it’s not a magic wand that will do the work for you. There’s a lot of effort involved in finding the right combination of plugins, chunks, etc. in order to shrink your bundle, but this plugin does help identify where those efforts can be directed to have the greatest return on time spent.