We built Webpack Monitor to help developers keep track of their webpack bundles through the development process, identify builds that introduce size issues, and provide information for making informed decisions about how to prioritize optimization.

We wanted to expand on the existing analyzers, notably the excellent webpack-bundle-analyzer, by creating a tool that integrates into the development process and provides analysis of webpack’s output over time. Allowing users to refer back to previous builds makes it possible to identify when bundles became bloated, what dependencies were responsible, and what can be done about it.

Overview

Webpack Monitor’s overview page is divided into three sections. The panels at the top are consistent throughout the app. Here you access key statistics about the ‘active build’ — the build you have currently selected.

Assets Chart

Build Size Chart

The assets chart tracks the three largest assets of your bundle and provides interesting insights about the effects of optimization. Have you ever created a new vendor asset without removing all that vendor code from app.js? I certainly have, and this makes it easy to spot.

The total size of the build project is here, which provides one way to navigate between active builds.

Build Composition

Finally, and with a due nod to Webpack Visualizer, the sunburst chart gives you all the information you need about your selected build in a beautiful interactive graphic. All the charts are rendered in D3 but it’s here that one can see what sets it apart from other charting / visualization libraries.

Build Data

On our Build Data page we display the individual files bundled by Webpack. No matter what the size of the file, even if it is just a byte, it’s included. Because if you shave just a few milliseconds off your time-to-interactive and if your app or website is used by 100 million people, you can save days of load time across your users.

Sample data available on the Build Data page

This information gives you the ability to make data driven decisions on optimizing your bundle for performance.

Toggling between builds allows you to compare the changes in the individual files between builds. That is the key in identifying extraneous files, large libraries that can be stripped or npm modules that fellow developers might have installed a different version of. With this information your team can amend these files them prior to deployment, ensuring awesome performance and user experience.

Recommendations

The recommendations page is awesome. At the top we have a summary that basically tells you how much you can reduce the size of your Webpack bundle if you take our recommendations into consideration. It will also tell you the percentage of how much you can reduce the size of your current bundle. Not only that, under the bar, it displays the current size of your bundle and the optimized size. And if that wasn’t good enough for you, for the quickest reference you can look at the potential savings size in red.

At this point you might be wondering, “How can I get a break down of this awesome summary and see what recommendations are offered???” Well if there are ways to optimize your bundle file then all you have to do is look right below the summary and it will essentially show you the same. The two recommendations we have so far are to minify with Babel and to remove unused CSS with Purify CSS. However, what’s different about the minification panel is that there could be multiple bars depending on how many JavaScript files could be minified. We even tell you which files could be minified and how much each file saves in addition to how much you can save by minifiying in total.

Check us out on Github and npm!