Which is Better Webpack Bundle Analysis Tools?
webpack-bundle-analyzer vs source-map-explorer vs bundlewatch vs stats-webpack-plugin vs webpack-visualizer-plugin vs webpack-dashboard
1 Year
webpack-bundle-analyzersource-map-explorerbundlewatchstats-webpack-pluginwebpack-visualizer-pluginwebpack-dashboard
What's Webpack Bundle Analysis Tools?

These npm packages are designed to help developers analyze and optimize their JavaScript bundles created by Webpack. They provide insights into the size, structure, and performance of the bundles, enabling developers to make informed decisions about code splitting, lazy loading, and overall optimization strategies. By using these tools, developers can identify large dependencies, visualize the bundle composition, and ensure that their applications are efficient and performant.

NPM Package Downloads Trend
Github Stars Ranking
Stat Detail
Package
Downloads
Stars
Size
Issues
Publish
License
webpack-bundle-analyzer5,737,71812,5731.23 MB306 months agoMIT
source-map-explorer601,4003,829352 kB57-Apache-2.0
bundlewatch100,49241849.3 kB293 months agoMIT
stats-webpack-plugin92,536164-106 years agoMIT
webpack-visualizer-plugin23,3311,692-498 years agoMIT
webpack-dashboard21,12613,86352.2 kB39a year agoMIT
Feature Comparison: webpack-bundle-analyzer vs source-map-explorer vs bundlewatch vs stats-webpack-plugin vs webpack-visualizer-plugin vs webpack-dashboard

Bundle Size Tracking

  • webpack-bundle-analyzer: Webpack Bundle Analyzer visualizes the size of your bundles and their contents, but it does not enforce size limits or track changes over time.
  • source-map-explorer: Source Map Explorer does not track bundle size over time but helps you understand the size of each module in your bundle, allowing you to optimize individual components rather than the overall size.
  • bundlewatch: Bundlewatch allows you to set size limits for your bundles and tracks changes over time. It provides alerts when bundle sizes exceed specified thresholds, helping maintain performance standards throughout development.
  • stats-webpack-plugin: Stats Webpack Plugin generates a stats file that includes size information for each module, but it does not provide tracking or alerts for size changes over time.
  • webpack-visualizer-plugin: Webpack Visualizer Plugin generates a static report of your bundle sizes, allowing for easy comparison, but it does not track changes over time.
  • webpack-dashboard: Webpack Dashboard focuses on build performance metrics rather than bundle size tracking, providing insights into build times and errors during development.

Visualization

  • webpack-bundle-analyzer: Webpack Bundle Analyzer provides an interactive treemap visualization of your bundle, making it easy to identify large dependencies and understand the structure of your application.
  • source-map-explorer: Source Map Explorer offers a detailed view of your minified files, allowing you to see which parts of your code contribute to the final bundle size, but it is less interactive than other tools.
  • bundlewatch: Bundlewatch provides a simple report of bundle sizes but lacks advanced visualization features. It focuses more on alerts and thresholds than visual representation.
  • stats-webpack-plugin: Stats Webpack Plugin generates a JSON stats file that can be used with other visualization tools, but it does not provide direct visual output itself.
  • webpack-visualizer-plugin: Webpack Visualizer Plugin generates a static HTML report that visually represents your bundle sizes, allowing for easy analysis and comparison.
  • webpack-dashboard: Webpack Dashboard offers a real-time view of build progress but does not provide detailed visualizations of bundle contents.

Integration with CI/CD

  • webpack-bundle-analyzer: Webpack Bundle Analyzer can be integrated into CI/CD workflows, but it is mainly used for analysis rather than enforcing size limits.
  • source-map-explorer: Source Map Explorer can be integrated into CI/CD pipelines, but it primarily focuses on analyzing individual builds rather than enforcing size limits.
  • bundlewatch: Bundlewatch is specifically designed for CI/CD integration, allowing you to enforce bundle size limits as part of your deployment process, ensuring that new changes do not bloat your application.
  • stats-webpack-plugin: Stats Webpack Plugin can be used in CI/CD environments to generate stats files, but it does not provide alerts or tracking for bundle size changes.
  • webpack-visualizer-plugin: Webpack Visualizer Plugin can be used in CI/CD pipelines to generate reports, but it does not enforce size limits or provide alerts.
  • webpack-dashboard: Webpack Dashboard is primarily a development tool and does not integrate directly with CI/CD processes for bundle analysis.

Ease of Use

  • webpack-bundle-analyzer: Webpack Bundle Analyzer is user-friendly and provides an intuitive interface for analyzing bundles, making it suitable for developers of all skill levels.
  • source-map-explorer: Source Map Explorer is straightforward to use, especially for developers familiar with source maps, but it requires additional steps to visualize the output effectively.
  • bundlewatch: Bundlewatch is easy to set up and integrates seamlessly into your workflow, making it a great choice for teams looking to enforce bundle size limits without much overhead.
  • stats-webpack-plugin: Stats Webpack Plugin is easy to configure but requires additional tools to visualize the generated stats file, which may add complexity.
  • webpack-visualizer-plugin: Webpack Visualizer Plugin is simple to use and generates static reports, but it may require additional configuration to fit into your workflow.
  • webpack-dashboard: Webpack Dashboard is designed for real-time feedback during development, making it easy to use for developers who want immediate insights into build performance.

Real-Time Feedback

  • webpack-bundle-analyzer: Webpack Bundle Analyzer provides real-time visual feedback during the build process, allowing developers to see the impact of their changes immediately.
  • source-map-explorer: Source Map Explorer does not offer real-time feedback; it analyzes completed builds rather than providing insights during development.
  • bundlewatch: Bundlewatch does not provide real-time feedback; it focuses on post-build analysis and alerts for size limits.
  • stats-webpack-plugin: Stats Webpack Plugin generates stats files after builds, lacking real-time feedback during the build process.
  • webpack-visualizer-plugin: Webpack Visualizer Plugin generates reports after builds, lacking real-time feedback during the build process.
  • webpack-dashboard: Webpack Dashboard excels in providing real-time feedback on build progress and performance metrics, enhancing the developer experience during development.
How to Choose: webpack-bundle-analyzer vs source-map-explorer vs bundlewatch vs stats-webpack-plugin vs webpack-visualizer-plugin vs webpack-dashboard
  • webpack-bundle-analyzer: Opt for Webpack Bundle Analyzer if you prefer an interactive, visual representation of your bundle. It provides a treemap visualization of your bundle contents, making it easy to spot large dependencies and understand the overall structure of your application.
  • source-map-explorer: Select Source Map Explorer if you need to analyze the contents of your minified JavaScript files and understand which parts of your code contribute to the final bundle size. It helps in visualizing the source maps, making it easier to identify large modules and dependencies.
  • bundlewatch: Choose Bundlewatch if you want to enforce bundle size limits and track changes over time. It integrates with your CI/CD pipeline to ensure that your bundle sizes do not exceed specified thresholds, providing a safeguard against unintentional bloat.
  • stats-webpack-plugin: Use Stats Webpack Plugin if you want to generate a stats file that provides detailed information about your Webpack build. This file can be used with other analysis tools to gain insights into the build process and performance metrics.
  • webpack-visualizer-plugin: Select Webpack Visualizer Plugin if you need a static HTML report of your bundle analysis. It generates a visual representation of your bundle sizes, allowing you to analyze and compare different builds easily.
  • webpack-dashboard: Choose Webpack Dashboard if you want a real-time dashboard that displays build progress and performance metrics during the development process. It enhances the developer experience by providing immediate feedback on build times and errors.
README for webpack-bundle-analyzer

npm node tests downloads

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').BundleAnalyzerPlugin;

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:

  1. Realize what's really inside your bundle
  2. Find out what modules make up the most of its size
  3. Find modules that got there by mistake
  4. 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 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|Default: parsed. Module sizes to show in report by default. Size definitions section describes what these values mean.| |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.|

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 (default: parsed)
  -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.

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.

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: