Analyzing Build Statistics

React Day Berlin - Fully Packed Day of Your Favorite React Content - Interview with Robert Haritonov

Analyzing build statistics is a good step towards understanding webpack better. Visualizing them helps you to understand the composition of your bundles.

Configuring Webpack#

To get suitable output, you need to do a couple of tweaks to the configuration. Most importantly, you have to enable two flags:

  • --profile to capture timing-related information. This is optional, but good to set.
  • --json to make webpack output statistics.

Here's the line of code you need to pipe the output to a file:


"scripts": {
"stats": "webpack --env production --profile --json > stats.json",
... },

The above is the basic setup you need, regardless of your webpack configuration. Execute npm run stats now. After a while you should find stats.json at your project root. This file can be pushed through a variety of tools to understand better what's going on.

Given you piggyback on the production target in the current setup, this process cleans the build directory! If you want to avoid that, set up a separate target where you don't clean.

Node API#

Stats can be captured through Node. Since stats can contain errors, so it's a good idea to handle that case separately:

const webpack = require('webpack');
const config = require('./webpack.config.js')('production');

webpack(config, (err, stats) => {
  if (err) {
    return console.error(err);

  if (stats.hasErrors()) {
    return console.error(stats.toString('errors-only'));


This technique can be valuable if you want to do further processing on stats although often the other solutions are enough.

StatsWebpackPlugin and WebpackStatsPlugin#

If you want to manage stats through a plugin, check out stats-webpack-plugin. It gives you a bit more control over the output. You can use it to exclude certain dependencies from the output.

webpack-stats-plugin is another option. It allows you to transform the data before outputting it.

Available Analysis Tools#

Even though having a look at the file itself gives you idea of what's going on, often it's preferable to use a particular tool for that. Consider the following.

The Official Analyse Tool#

The Official Analyse Tool

The official analyse tool gives you recommendations and a good idea of your application's dependency graph. It can be run locally as well.

Webpack Visualizer#

Webpack Visualizer

Webpack Visualizer provides a pie chart showing your bundle composition allowing to understand which dependencies contribute to the size of the overall result.


duplicate-package-checker-webpack-plugin warns you if it finds single package multiple times in your build. This situation can be hard to spot otherwise.

Webpack Chart#

Webpack Chart

Webpack Chart is another similar visualization.


webpack-unused prints out unused files and can be used to understand which assets are no longer used and can be removed from the project.

Stellar Webpack#

Stellar Webpack

Stellar Webpack gives a universe based visualization and allows you to examine your application in a 3D form.


webpack-bundle-tracker can capture data while webpack is compiling. It uses JSON for this purpose.



webpack-bundle-analyzer provides a zoomable treemap.


webpack-bundle-size-analyzer gives a text based composition.

$ webpack-bundle-size-analyzer stats.json
react: 93.99 KB (74.9%)
purecss: 15.56 KB (12.4%)
style-loader: 6.99 KB (5.57%)
fbjs: 5.02 KB (4.00%)
object-assign: 1.95 KB (1.55%)
css-loader: 1.47 KB (1.17%)
<self>: 572 B (0.445%)


inspectpack can be used for figuring out specific places of code to improve.

$ inspectpack --action=duplicates --bundle=bundle.js
## Summary

* Bundle:
    * Path:                /PATH/TO/bundle.js
    * Bytes (min):         1678533
* Missed Duplicates:
    * Num Unique Files:    116
    * Num Extra Files:     131
    * Extra Bytes (min):   253955
    * Pct of Bundle Size:  15 %

Independent Tools#

In addition to tools that work with webpack output, there are a couple that are webpack agnostic and worth a mention.


source-map-explorer is a tool independent from webpack. It allows you to get insight into your build by using source maps. It gives a treemap based visualization showing what code contributes to the result.



madge is another independent tool that can output a graph based on module input. The graph output allows you to understand the dependencies of your project in greater detail.


When you are optimizing the size of your bundle output, these tools are invaluable. The official tool has the most functionality, but even a basic visualization can reveal problem spots. You can use the same technique with old projects to understand their composition.

To recap:

  • Webpack allows you to extract a JSON file containing information about the build. The information can include the build composition and timing.
  • The generated information can be analyzed using various tools that give insight into aspects such as the bundle composition.
  • Understanding the bundles is the key to insights on how to optimize the overall size, what to load and when. It can also reveal bigger issues, such as redundant data.
  • You can find third party tools that don't depend on webpack but are still valuable for analysis.

You'll learn to tune webpack performance in the next chapter.

Previous chapterSeparating a Manifest
Next chapterPerformance

This book is available through Leanpub (digital), Amazon (paperback), and Kindle (digital). By purchasing the book you support the development of further content. A part of profit (~30%) goes to Tobias Koppers, the author of webpack.

Need help?