Many modern web applications are composed of lots of JavaScript and even more third-party dependencies. Bundlers like WebPack, Rollup, and ESBuild simplify building and distributing bundles of code to a user’s browser. However, bundlers are only as smart as the code they’re processing, and it’s easy to bog down the system in unexpected ways. This is where bundle analysis tools can help a developer find mistakes and bloat they could optimize to provide a better application to their users.
I recently ran into an issue where a set of images that totaled nearly 15MB was included in our design library used by every consumer-facing application in the project. There’s no bug in the code, so nobody noticed the bloat until app load times skyrocketed to nearly 12 seconds! We used bundle visualization tools to identify the culprit images and found better ways to include them. This process opened my eyes to a side of web app development I hadn’t worried much about before: bundle analysis.
Bundle Analysis
Bundle analysis is the use of tools to better understand the code shipped to end users. Many of these tools provide a visualization of the modules and structure in the bundler’s output. You can use this information to optimize bandwidth, performance, and load times.
I’ve been primarily using an NPM package called source-map-explorer for these tasks. It is lightweight and easy to use. Its output is simple and easy for me to parse at a high level. Another NPM package in this space that I’ve used before is webpack-bundler-analyzer. It provides a similar output optimized for WebPack bundles. I also recently learned that Google’s open-source Lighthouse tools suite has TreeMap, a feature that does bundle analysis for live sites. That makes this functionality conveniently available in Chrome dev tools!
Analyzing Effectively
Keep an eye out for duplicate dependencies. If you see the same file name appear in the visualization multiple times, this might be an easy place to make improvements. The resolution will depend on your use case, but you might consider using compatible versions of transitive dependencies or looking into peer dependencies.
Aside from duplicate dependencies, you might also keep an eye out for dependencies you’re unfamiliar with. A “what on earth is that?” moment might help you uncover unused or unnecessary packages.
There will always be a biggest chunk of your bundle. And sometimes the biggest piece of the bundle is the biggest for a reason. Rather than always trying to optimize away the largest piece of the visualization, weigh the size of the chunk against its importance to your application. Building a React app? The React dependencies in your node_modules will probably be a significant piece of your analysis, but that’s nothing to worry about. But the source file called “helpers.ts” clocking in at 2MB? That’s probably something to consider investigating.
Similarly, because there will always be a biggest piece of the bundle, there is no end-game in this space. There are only incremental improvements. Celebrate the gains that you can make and then move on. There are diminishing returns to chipping away at the bundle size forever.
Bundle analysis is only beneficial if it’s being performed periodically. I have tried to make this a part of the project’s lifecycle by introducing a conservative size-limit CI job. When that job fails, we know it’s time to re-run our bundle analysis and check for new inefficiencies.
Bundle Analysis: A Highly Effective Tool
Bundle analysis can be a highly effective tool in your web development tool kit. If you know how to use it and what to watch for, you can maintain an optimized and clean bundle.