webpack-bundle-analyzer vs webpack-dashboard

Analyzing and Visualizing Webpack Build Performance

webpack-bundle-analyzer and webpack-dashboard are both tools designed to help developers understand and optimize their Webpack builds, but they serve different primary purposes. webpack-bundle-analyzer focuses on visualizing the contents of your bundles as an interactive treemap, allowing you to see exactly which modules contribute most to your file size. This is critical for identifying bloated dependencies and optimizing code splitting. webpack-dashboard, on the other hand, was designed to replace the standard Webpack output in the terminal with a rich, real-time dashboard showing build progress, module compilation times, and asset sizes. However, it is crucial to note that webpack-dashboard is no longer actively maintained and has significant compatibility issues with modern Webpack versions, whereas webpack-bundle-analyzer remains a standard, robust tool in the ecosystem.

Npm Package Weekly Downloads Trend

3 Years

Github Stars Ranking

Stat Detail

Package	Downloads	Stars	Size	Issues	Publish	License
Package	Downloads	Stars	Size	Issues	Publish	License
webpack-bundle-analyzer	0	12,657	1.46 MB	27	16 days ago	MIT
webpack-dashboard	0	13,964	52.2 kB	40	3 years ago	MIT

webpack-bundle-analyzer vs webpack-dashboard: Build Insights Compared

When optimizing a Webpack build, you generally face two distinct challenges: understanding what is inside your bundles (size optimization) and monitoring how long the build takes (performance optimization). webpack-bundle-analyzer and webpack-dashboard were created to solve these respective problems. However, their current status in the ecosystem is vastly different. One is a vital, active tool for every frontend architect; the other is a legacy package that should be avoided.

📊 Visualizing Bundle Composition: The Core Strength of webpack-bundle-analyzer

webpack-bundle-analyzer generates an interactive treemap visualization of your bundle contents. It parses the Webpack stats file and renders a zoomable map where each rectangle represents a module. The size of the rectangle corresponds to the module's size in the final bundle.

This is indispensable for spotting "bundle bloat." For example, you might accidentally import an entire icon library when you only needed one icon, or include a heavy date-fns package instead of a lighter alternative. The visual nature of this tool makes these issues obvious immediately.

// webpack.config.js
const { BundleAnalyzerPlugin } = require('webpack-bundle-analyzer');

module.exports = {
  // ... other config
  plugins: [
    new BundleAnalyzerPlugin({
      analyzerMode: 'static', // Generates a static HTML file
      openAnalyzer: false,    // Don't auto-open in browser (useful for CI)
      reportFilename: 'bundle-report.html'
    })
  ]
};

You can also run it as a CLI command without changing your config, which is great for one-off analysis:

npx webpack-bundle-analyzer ./dist/stats.json

webpack-dashboard did not offer this kind of deep module-level visualization. Its focus was entirely on the build process itself, not the internal composition of the assets. If your goal is to shrink your JavaScript files, webpack-dashboard provides no help here.

⚡ Monitoring Build Performance: Terminal UI vs Modern Alternatives

webpack-dashboard was originally created to make the Webpack terminal output more readable. Instead of the wall of text logs, it provided a clean UI showing:

Build status (compiling, done, failed)
Module compilation times
Asset sizes
Warnings and errors

It worked by wrapping the Webpack compiler and intercepting stats.

// OLD/DEPRECATED usage pattern
const Dashboard = require('webpack-dashboard/plugin');
const DashboardPlugin = Dashboard.plugin;

module.exports = {
  plugins: [
    new DashboardPlugin()
  ]
};

The Problem: webpack-dashboard relies on internal Webpack APIs that have changed significantly, especially in Webpack 5. The package has not been updated to match these changes. Using it today often results in crashes, missing data, or complete failure to run. The maintainers have effectively abandoned the project.

webpack-bundle-analyzer does not replace the terminal output. It runs after the build (or during, in server mode) to analyze the result. It does not show you real-time compilation speed per module during the build process. If you need to measure build speed, you should use the native --stats flag or a maintained alternative like speed-measure-webpack-plugin.

// Modern alternative for timing: speed-measure-webpack-plugin
const SpeedMeasurePlugin = require("speed-measure-webpack-plugin");
const smp = new SpeedMeasurePlugin();

module.exports = smp.wrap({
  // ... your normal webpack config
  plugins: [
    // ... your plugins
  ]
});

🛠️ Integration and Workflow

CI/CD Integration

webpack-bundle-analyzer excels in Continuous Integration pipelines. Because it can generate a static HTML report, you can archive this file as a build artifact. Teams often review these reports during code reviews to ensure no one accidentally merged a massive dependency.

# Example CI step
npm run build -- --json > stats.json
npx webpack-bundle-analyzer stats.json --mode static
# Upload bundle-report.html as an artifact

webpack-dashboard was designed for local development only. It hooks into the terminal session and requires an interactive TTY. It cannot generate reports for CI, and its instability makes it unsuitable for automated environments.

Webpack Version Compatibility

webpack-bundle-analyzer: Fully compatible with Webpack 4 and Webpack 5. It reads the standard stats JSON format, which is stable and well-documented.
webpack-dashboard: Broken with Webpack 5. It attempts to access compiler internals that no longer exist or have changed signatures. You will likely encounter errors like TypeError: Cannot read property 'hooks' of undefined or similar cryptic failures.

🚨 Deprecation Warning: Do Not Use webpack-dashboard

It is critical to state clearly: webpack-dashboard is deprecated and unmaintained.

The GitHub repository has not seen meaningful updates in years. Issues regarding Webpack 5 compatibility remain unresolved. Continuing to use this package introduces unnecessary risk to your build pipeline. If you encounter a tutorial or legacy codebase using it, plan to remove it immediately.

For real-time build feedback in modern setups, rely on:

Webpack's native stats: Use stats: { modules: false, chunks: false } in your config to reduce noise.
webpack-bundle-analyzer in server mode for live updates during development:

// Development config with live analyzer server
new BundleAnalyzerPlugin({
  analyzerMode: 'server',
  openAnalyzer: true,
  generateStatsFile: false
})

speed-measure-webpack-plugin for detailed timing breakdowns.

📌 Summary Comparison

Feature	`webpack-bundle-analyzer`	`webpack-dashboard`
Primary Goal	Visualize bundle contents & size	Terminal UI for build progress
Maintenance Status	✅ Active & Maintained	❌ Deprecated & Abandoned
Webpack 5 Support	✅ Full Support	❌ Broken / Unreliable
CI/CD Friendly	✅ Yes (Static HTML reports)	❌ No (Interactive terminal only)
Module Visualization	✅ Interactive Treemap	❌ None
Build Timing	❌ No (Post-build analysis)	⚠️ Was yes, now broken
Recommendation	Use in every project	Do NOT use

💡 The Big Picture

If you are making an architectural decision today, the choice is straightforward:

Adopt webpack-bundle-analyzer as a standard part of your build process. It provides actionable insights into bundle size, helping you keep your application fast and efficient. Configure it to run on every production build and archive the reports.

Remove webpack-dashboard from any project you encounter. It solves a problem (pretty terminal logs) that is less critical than build stability, and its solution is now obsolete. Replace its intended functionality with native Webpack stats configuration or maintained plugins like speed-measure-webpack-plugin if build timing is a bottleneck.

In modern frontend architecture, tooling stability is paramount. Stick to tools that are actively maintained and align with current Webpack standards. webpack-bundle-analyzer fits this criteria perfectly; webpack-dashboard does not.

How to Choose: webpack-bundle-analyzer vs webpack-dashboard

webpack-bundle-analyzer:
Choose webpack-bundle-analyzer when your primary goal is to reduce bundle size and optimize load times. It is the industry standard for visualizing exactly what code is included in your production bundles, helping you spot large dependencies or accidental duplicates. It works reliably with Webpack 4 and 5, supports static HTML generation for CI/CD pipelines, and requires minimal configuration to integrate into existing workflows.
webpack-dashboard:
Do NOT choose webpack-dashboard for new projects. This package has been deprecated and is unmaintained, leading to frequent breakage with modern Webpack versions (especially Webpack 5) and Node.js environments. While it originally offered a nice terminal UI for build metrics, its core functionality (reporting build stats) is now better handled by native Webpack stats, webpack-bundle-analyzer, or modern alternatives like speed-measure-webpack-plugin. Stick to maintained tools to avoid unstable builds.

Popular Comparisons

webpack-bundle-analyzer

webpack-dashboard

README for webpack-bundle-analyzer

Webpack Bundle Analyzer

Visualize size of webpack output files with an interactive zoomable treemap.

Install

# NPM
npm install --save-dev webpack-bundle-analyzer
# Yarn
yarn add -D webpack-bundle-analyzer

Usage (as a plugin)

const { BundleAnalyzerPlugin } = require("webpack-bundle-analyzer");

module.exports = {
  plugins: [new BundleAnalyzerPlugin()],
};

It will create an interactive treemap visualization of the contents of all your bundles.

webpack bundle analyzer zoomable treemap

This module will help you:

Realize what's really inside your bundle
Find out what modules make up the most of its size
Find modules that got there by mistake
Optimize it!

And the best thing is it supports minified bundles! It parses them to get real size of bundled modules. And it also shows their gzipped, Brotli, or Zstandard sizes!

Options (for plugin)

new BundleAnalyzerPlugin(options?: object)

Name	Type	Description
`analyzerMode`	One of: `server`, `static`, `json`, `disabled`	Default: `server`. In `server` mode analyzer will start HTTP server to show bundle report. In `static` mode single HTML file with bundle report will be generated. In `json` mode single JSON file with bundle report will be generated. In `disabled` mode you can use this plugin to just generate Webpack Stats JSON file by setting `generateStatsFile` to `true`.
`analyzerHost`	`{String}`	Default: `127.0.0.1`. Host that will be used in `server` mode to start HTTP server.
`analyzerPort`	`{Number}` or `auto`	Default: `8888`. Port that will be used in `server` mode to start HTTP server. If `analyzerPort` is `auto`, the operating system will assign an arbitrary unused port
`analyzerUrl`	`{Function}` called with `{ listenHost: string, listenHost: string, boundAddress: server.address}`. server.address comes from Node.js	Default: `http://${listenHost}:${boundAddress.port}`. The URL printed to console with server mode.
`reportFilename`	`{String}`	Default: `report.html`. Path to bundle report file that will be generated in `static` mode. It can be either an absolute path or a path relative to a bundle output directory (which is output.path in webpack config).
`reportTitle`	`{String\|function}`	Default: function that returns pretty printed current date and time. Content of the HTML `title` element; or a function of the form `() => string` that provides the content.
`defaultSizes`	One of: `stat`, `parsed`, `gzip`, `brotli`	Default: `parsed`. Module sizes to show in report by default. Size definitions section describes what these values mean.
`compressionAlgorithm`	One of: `gzip`, `brotli`, `zstd`	Default: `gzip`. Compression type used to calculate the compressed module sizes.
`openAnalyzer`	`{Boolean}`	Default: `true`. Automatically open report in default browser.
`generateStatsFile`	`{Boolean}`	Default: `false`. If `true`, webpack stats JSON file will be generated in bundle output directory
`statsFilename`	`{String}`	Default: `stats.json`. Name of webpack stats JSON file that will be generated if `generateStatsFile` is `true`. It can be either an absolute path or a path relative to a bundle output directory (which is output.path in webpack config).
`statsOptions`	`null` or `{Object}`	Default: `null`. Options for `stats.toJson()` method. For example you can exclude sources of your modules from stats file with `source: false` option. See more options here.
`excludeAssets`	`{null\|pattern\|pattern[]}` where `pattern` equals to `{String\|RegExp\|function}`	Default: `null`. Patterns that will be used to match against asset names to exclude them from the report. If pattern is a string it will be converted to RegExp via `new RegExp(str)`. If pattern is a function it should have the following signature `(assetName: string) => boolean` and should return `true` to exclude matching asset. If multiple patterns are provided asset should match at least one of them to be excluded.
`logLevel`	One of: `info`, `warn`, `error`, `silent`	Default: `info`. Used to control how much details the plugin outputs.

Absolute output paths

reportFilename and statsFilename can be absolute paths. Use absolute paths when you want the generated report or stats file to be written outside webpack's output.path. Relative paths are resolved against the bundle output directory.

const path = require("node:path");
const { BundleAnalyzerPlugin } = require("webpack-bundle-analyzer");

module.exports = {
  plugins: [
    new BundleAnalyzerPlugin({
      analyzerMode: "static",
      reportFilename: path.resolve(__dirname, "reports/report.html"),
      generateStatsFile: true,
      statsFilename: path.resolve(__dirname, "reports/stats.json"),
    }),
  ],
};

Usage (as a CLI utility)

You can analyze an existing bundle if you have a webpack stats JSON file.

You can generate it using BundleAnalyzerPlugin with generateStatsFile option set to true or with this simple command:

webpack --profile --json > stats.json

If you're on Windows and using PowerShell, you can generate the stats file with this command to avoid BOM issues:

webpack --profile --json | Out-file 'stats.json' -Encoding OEM

Then you can run the CLI tool.

webpack-bundle-analyzer bundle/output/path/stats.json

Options (for CLI)

webpack-bundle-analyzer <bundleStatsFile> [bundleDir] [options]

Arguments are documented below:

`bundleStatsFile`

Path to webpack stats JSON file

`bundleDir`

Directory containing all generated bundles.

`options`

  -V, --version                   output the version number
  -m, --mode <mode>               Analyzer mode. Should be `server`, `static` or `json`.
                                  In `server` mode analyzer will start HTTP server to show bundle report.
                                  In `static` mode single HTML file with bundle report will be generated.
                                  In `json` mode single JSON file with bundle report will be generated. (default: server)
  -h, --host <host>               Host that will be used in `server` mode to start HTTP server. (default: 127.0.0.1)
  -p, --port <n>                  Port that will be used in `server` mode to start HTTP server. Should be a number or `auto` (default: 8888)
  -r, --report <file>             Path to bundle report file that will be generated in `static` mode. (default: report.html)
  -t, --title <title>             String to use in title element of html report. (default: pretty printed current date)
  -s, --default-sizes <type>      Module sizes to show in treemap by default.
                                  Possible values: stat, parsed, gzip, brotli, zstd (default: parsed)
  --compression-algorithm <type>  Compression algorithm that will be used to calculate the compressed module sizes.
                                  Possible values: gzip, brotli, zstd (default: gzip)
  -O, --no-open                   Don't open report in default browser automatically.
  -e, --exclude <regexp>          Assets that should be excluded from the report.
                                  Can be specified multiple times.
  -l, --log-level <level>         Log level.
                                  Possible values: debug, info, warn, error, silent (default: info)
  -h, --help                      output usage information

Size definitions

webpack-bundle-analyzer reports three values for sizes. defaultSizes can be used to control which of these is shown by default. The different reported sizes are:

`stat`

This is the "input" size of your files, before any transformations like minification.

It is called "stat size" because it's obtained from Webpack's stats object.

`parsed`

This is the "output" size of your files. If you're using a Webpack plugin such as Uglify, then this value will reflect the minified size of your code.

`gzip`

This is the size of running the parsed bundles/modules through gzip compression.

`brotli`

This is the size of running the parsed bundles/modules through Brotli compression.

`zstd`

This is the size of running the parsed bundles/modules through Zstandard compression. (Node.js 22.15.0+ is required for this feature)

Selecting Which Chunks to Display

When opened, the report displays all of the Webpack chunks for your project. It's possible to filter to a more specific list of chunks by using the sidebar or the chunk context menu.

Sidebar

The Sidebar Menu can be opened by clicking the > button at the top left of the report. You can select or deselect chunks to display under the "Show chunks" heading there.

Chunk Context Menu

The Chunk Context Menu can be opened by right-clicking or Ctrl-clicking on a specific chunk in the report. It provides the following options:

Hide chunk: Hides the selected chunk
Hide all other chunks: Hides all chunks besides the selected one
Show all chunks: Un-hides any hidden chunks, returning the report to its initial, unfiltered view

Troubleshooting

I don't see `gzip` or `parsed` sizes, it only shows `stat` size

It happens when webpack-bundle-analyzer analyzes files that don't actually exist in your file system, for example when you work with webpack-dev-server that keeps all the files in RAM. If you use webpack-bundle-analyzer as a plugin you won't get any errors, however if you run it via CLI you get the error message in terminal:

Error parsing bundle asset "your_bundle_name.bundle.js": no such file
No bundles were parsed. Analyzer will show only original module sizes from stats file.

To get more information about it you can read issue #147.

Cannot display report in Jenkins due to sandboxed iframe

When viewing a static HTML report through Jenkins (for example with the HTML Publisher plugin), the page can appear blank. Jenkins serves HTML inside a sandboxed iframe that blocks scripts by default, and the report needs JavaScript to render.

This is a Jenkins Content Security Policy restriction, not a bug in webpack-bundle-analyzer. To view the report you need to relax Jenkins CSP for Directory Browser Support. See issue #168 for details and an example hudson.model.DirectoryBrowserSupport.CSP setting.

`stats.json` has limited output

If your generated stats.json contains limited information, check your Webpack configuration. Using stats: 'error-only' limits the information included in the generated stats file.

Remove stats: 'error-only' or use a more detailed stats configuration when generating the stats file for webpack-bundle-analyzer.

Other tools

Statoscope - Webpack bundle analyzing tool to find out why a certain module was bundled (and more features, including interactive treemap)

Maintainers

Yuriy Grunin

Vesa Laakso

Contributing

Check out CONTRIBUTING.md for instructions on contributing :tada: