webpack-bundle-analyzer vs webpack-dashboard
Webpack Visualization Tools
Search packages..
webpack-bundle-analyzerwebpack-dashboardSimilar Packages:

Webpack Visualization Tools

Webpack visualization tools help developers analyze and understand the output of their Webpack builds. These tools provide insights into the size and structure of the generated bundles, allowing for better optimization and performance tuning. By visualizing the contents of the bundles, developers can identify large modules, unused code, and other inefficiencies that can be addressed to reduce load times and improve the overall performance of web applications. webpack-bundle-analyzer creates an interactive treemap visualization of the bundle, while webpack-dashboard provides a real-time dashboard with build statistics and performance metrics.

Npm Package Weekly Downloads Trend

3 Years

Github Stars Ranking

Stat Detail

Package
Downloads
Stars
Size
Issues
Publish
License
webpack-bundle-analyzer10,833,14612,6821.35 MB242 months agoMIT
webpack-dashboard36,05414,18552.2 kB393 years agoMIT

Feature Comparison: webpack-bundle-analyzer vs webpack-dashboard

Visualization Type

  • webpack-bundle-analyzer:

    webpack-bundle-analyzer provides an interactive treemap visualization of your bundle, allowing you to see the size and structure of each module and dependency. This visual representation helps identify large modules and optimize your bundle more effectively.

  • webpack-dashboard:

    webpack-dashboard displays build progress and statistics in a real-time dashboard format directly in your terminal. While it does not provide detailed visualizations of the bundle contents, it offers quick insights into build performance and completion times.

Real-time Updates

  • webpack-bundle-analyzer:

    webpack-bundle-analyzer does not provide real-time updates during the build process. The analysis is performed after the build is complete, and the visualization is generated based on the final bundle output.

  • webpack-dashboard:

    webpack-dashboard offers real-time updates during the build process, displaying live statistics such as build time, file sizes, and progress. This feature helps developers monitor the build in real-time and identify performance bottlenecks.

Integration

  • webpack-bundle-analyzer:

    webpack-bundle-analyzer integrates seamlessly with Webpack and can be added as a plugin in your Webpack configuration. It can also be run as a standalone CLI tool to analyze existing bundles.

  • webpack-dashboard:

    webpack-dashboard integrates with Webpack's build process and enhances the output displayed in the terminal. It requires minimal configuration and works alongside other Webpack plugins and loaders.

Optimization Insights

  • webpack-bundle-analyzer:

    webpack-bundle-analyzer provides detailed insights into the size and composition of your bundles, helping you identify large modules, duplicate dependencies, and potential areas for optimization. It is particularly useful for in-depth analysis and optimizing bundle size.

  • webpack-dashboard:

    webpack-dashboard focuses on providing real-time build statistics and performance metrics but does not offer detailed insights into bundle optimization. It is more suited for monitoring build performance rather than analyzing bundle contents.

Ease of Use: Code Examples

  • webpack-bundle-analyzer:

    webpack-bundle-analyzer is easy to use and requires minimal setup. Simply add it as a plugin in your Webpack configuration, and it will generate a visualization of your bundle after each build.

    Example Webpack Configuration:

    const BundleAnalyzerPlugin = require('webpack-bundle-analyzer').BundleAnalyzerPlugin;

module.exports = {
  // ... your existing Webpack configuration ...
  plugins: [
    new BundleAnalyzerPlugin(),
  ],
};

    After running your Webpack build, an interactive treemap visualization will be displayed in your browser, showing the size and structure of your bundle.

  • webpack-dashboard:

    webpack-dashboard is also easy to set up and requires minimal configuration. Simply install the package and add it to your Webpack configuration to enhance the terminal output during builds.

    Example Webpack Configuration:

    const DashboardPlugin = require('webpack-dashboard/plugin');

module.exports = {
  // ... your existing Webpack configuration ...
  plugins: [
    new DashboardPlugin(),
  ],
};

    After adding the plugin and running your Webpack build, you will see a real-time dashboard in your terminal displaying build progress, file sizes, and other statistics.

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

  • webpack-bundle-analyzer:

    Choose webpack-bundle-analyzer if you need a detailed, interactive visualization of your bundle's contents. It helps identify large modules, dependencies, and potential areas for optimization, making it ideal for in-depth analysis.

  • webpack-dashboard:

    Choose webpack-dashboard if you want a simple, real-time dashboard that displays build progress, statistics, and performance metrics directly in your terminal. It enhances the developer experience during the build process without adding significant overhead.

Similar Npm Packages to webpack-bundle-analyzer

webpack-bundle-analyzer is a powerful tool that helps developers visualize the size of their webpack output files with an interactive treemap. This tool provides insights into the composition of your bundles, making it easier to identify large dependencies and optimize your application's performance. By analyzing the bundle size, developers can make informed decisions about code splitting, lazy loading, and other optimization techniques.

While webpack-bundle-analyzer is a popular choice for analyzing bundle sizes, there are several alternatives that offer similar functionalities. Here are a few noteworthy options:

  • bundlewatch is a tool designed to monitor the size of your bundles over time. It allows you to set size limits for your bundles and will notify you if any of them exceed the specified limits. This is particularly useful for maintaining performance standards in large projects and ensuring that new changes do not inadvertently bloat the bundle size.
  • source-map-explorer is a tool that analyzes JavaScript source maps to provide insights into the size of your JavaScript files. It helps you understand which parts of your code contribute to the overall bundle size, making it easier to identify and eliminate unnecessary code. This tool is especially useful for projects that use minification and bundling techniques.
  • stats-webpack-plugin is a webpack plugin that generates a JSON file containing information about the output files. This plugin can be used in conjunction with other tools to analyze the bundle size and structure. It provides a comprehensive overview of the build process, making it easier to debug and optimize your webpack configurations.
  • webpack-dashboard is a tool that provides a visual representation of your webpack build process in the terminal. While it does not focus solely on bundle size analysis, it offers real-time feedback on build performance, allowing developers to identify bottlenecks and optimize their build process.
  • webpack-visualizer-plugin is a plugin that generates a visual representation of your webpack bundle. It creates an HTML file that displays the size of each module in your bundle, helping you understand the structure and size distribution of your code. This tool is useful for quickly identifying large modules and optimizing your bundle.

To see how webpack-bundle-analyzer compares with these alternatives, check out the comparison: Comparing bundlewatch vs source-map-explorer vs stats-webpack-plugin vs webpack-bundle-analyzer vs webpack-dashboard vs webpack-visualizer-plugin.

Similar Npm Packages to webpack-dashboard

webpack-dashboard is a tool designed to provide a more user-friendly and visually appealing interface for monitoring the progress of Webpack builds. It enhances the command-line experience by presenting build statistics and logs in a dashboard format, making it easier for developers to track the status of their builds in real-time. This can be particularly useful in large projects where build times can be significant, allowing developers to quickly identify issues and optimize their build process.

While webpack-dashboard offers a great way to visualize build progress, there are alternatives that also provide insights into Webpack bundles. One notable alternative is:

  • webpack-bundle-analyzer. This tool provides a visual representation of the size of Webpack output files with an interactive zoomable treemap. It helps developers understand the composition of their bundles, identify large dependencies, and optimize their applications by reducing bundle size. By analyzing the bundle, developers can make informed decisions about code splitting, lazy loading, and other performance optimizations. If your primary goal is to analyze and optimize your bundle size rather than just monitor build progress, webpack-bundle-analyzer is an excellent choice.

To see how webpack-dashboard compares with webpack-bundle-analyzer, check out the comparison: Comparing webpack-bundle-analyzer vs webpack-dashboard.

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, Brotli, or Zstandard sizes!

Options (for plugin)

new BundleAnalyzerPlugin(options?: object)
NameTypeDescription
analyzerModeOne of: server, static, json, disabledDefault: 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 autoDefault: 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.jsDefault: 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.
defaultSizesOne of: stat, parsed, gzip, brotliDefault: parsed. Module sizes to show in report by default. Size definitions section describes what these values mean.
compressionAlgorithmOne of: gzip, brotli, zstdDefault: 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).
statsOptionsnull 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.
logLevelOne of: info, warn, error, silentDefault: 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, 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.

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:

npm-compare.com is an independent website designed to help developers choose the most suitable npm packages. We are not affiliated with npm, Inc, the official website for the npm registry. Note that npm is a registered trademark of npm, Inc. Please share your feedback via our GitHub repository. For more details, please refer to our Terms & Privacy.