Getting the most out of Webpack(er), Part 1
Diagnosing your setup with Webpack Bundle Analyzer
However, Webpacker didn’t ship with a primer on performance pitfalls to watch out for when Webpackifying a large, legacy code-laden monolith, and, well, we ran into a few.
Webpack Bundle Analyzer
The Webpack Bundle Analyzer plugin is one of several options for visualizing or otherwise introspecting on the actual chunks of code output by Webpack. It’s a great tool for manually checking whether your myriad Webpack configuration options and plugins are set up correctly and performing the expected transformations upon your code. It also just looks really freaking cool:
The code snippets in this blog are from our Webpacker config¹, but it should be trivial to translate them to a vanilla Webpack setup. Gotta love leaky abstractions!
First off, add the package to your project:
yarn add webpack-bundle-analyzer
Next, import and initialize the plugin in one of the environment-specific configuration files or in the base
Most examples showing how to use the Bundle Analyzer plugin have it being used in development mode, but we’ve found that it actually works best in production mode. Now, that’s definitely not to suggest that you should leave the plugin active when deploying an app to production. The plugin adds quite a bit of overhead to a build, and it’s definitely not necessary (or even useful) in a live production build. However, by running Webpack locally in production mode, the bundles displayed in the analyzer will be a much more accurate representation of what we’re actually shipping off to users. Vendor dependencies like React will be much smaller, as the production build removes a ton of helpful but development-only cruft, and, as a bonus, the analyzer will display three different sizes for each bundle:
- Stat size — the size of the chunk before Webpack has performed any magic on it.
- Parsed size — the size of the processed chunk (post-uglification/minification/etc).
- Gzipped size — the size of the processed chunk after it’s been gzipped.
At Flatiron, we use the gzipped figure for tracking changes in bundle size because it represents how much data is actually going to be sent over the wire when a user’s browser makes a request for a particular bundle.
To start the Bundle Analyzer plugin’s server, run the following command:
After Webpack is done compiling, you should see this output in your terminal:
Webpack Bundle Analyzer is started at http://127.0.0.1:8888
Use Ctrl+C to close it
And that’s it! We now have all of the tools that we’ll need on our bundle-trimming adventures. Join us in part 2 to dive into some of the issues we identified that Webpack and Webpacker’s defaults weren’t accounting for and how we fixed them.
Thanks for reading!
- Webpacker is nearing a stabilization release centered on Webpack 4, but at the time of writing it remains in beta. Consequently, we’re running Webpacker 3.5.3 and Webpack 3.12.1 in production.