This is the first day of my participation in the first Wenwen Challenge 2022.First challenge in 2022

introduce

It is believed that many beginners do not know how to optimize the performance when finishing the project. In fact, after the birth of Webpack, a lot of visual analysis tools for packages appeared soon, allowing us to clearly see the resource occupation of each module, so as to start to reduce the optimization.

Webpack-bundle-analyzer is a visualization analysis tool for Webpacks. We’ve talked about a lot of package visualization analysis tools, such as the early Webpack-Visualizer-plugin, but the last update was five years ago. The current mainstream is WebPack-Bundle-Analyzer, which was last updated three months ago, and WebPack5 is working properly, as well as visually pleasing and more straightforward to see the percentage of resources per package.

The diagram below:

The installation

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

use

Once we had installed it, we couldn’t make a judgment call to introduce it directly, deploying packaging in automated servers like Jenkins and sometimes getting stuck. This is not necessary because by default the server mode is newly enabled and a new service is started locally, and most of the time we will basically just view the analysis locally.

Let’s now write a specific instruction in package.json specifically for packaging analysis. As follows:

"scripts": {
    "build:report": "webpack --mode production --progress",}Copy the code

We added a new command called Build: Report, which we will type only later before building the visual analysis.

So how do we handle the introduction of the Webpack plugin WebPack-bundle-Analyzer for this directive?

PM provides a variable called npM_lifecycle_event, which returns the name of the currently running script, such as dev, build, test, and so on. Here we can use this variable to differentiate the command currently executed within the same script file. As follows:

// webpack.config.js
const plugins = []
const TARGET = process.env.npm_lifecycle_event;
if (TARGET == "build:report") {
  const BundleAnalyzerPlugin = require('webpack-bundle-analyzer').BundleAnalyzerPlugin;
  plugins.push(new BundleAnalyzerPlugin({
    analyzerMode: 'server'.// Default value: server, static, JSON, and disabled
    analyzerHost: '127.0.0.1'.// Default value: 127.0.0.1 if the host in server mode starts the HTTP server.
    analyzerPort: 8888.// Default value: 8888, the port used in server mode
    reportFilename:"report.html".// Default: report.html, the pathname of the bundle report file generated in static mode
    openAnalyzer:true.// Default: true, whether to open the report automatically in the default browser}}))module.exports = {
    // ...
    plugins
}
Copy the code

There are currently four modes of WebPack-Bundle-Analyzer:

  • Server mode: The analyzer will start the HTTP server to display the bundle report.
  • Static mode: Generate a single HTML file with a bundled report.
  • Json schema: Generate a single JSON file with a bundled report.
  • Disabled mode: Generates a Webpack Stats JSON file.

Now we just run:

# NPM
npm run build:report
# Yarn 
yarn build:report
Copy the code

You can automatically open a local service to view and analyze the package usage of the current project.

Here we can move in different blocks and see various size representations occur:

  • Stat size: Original size, or the size of the file before it is processed.

  • Parsed Size: This is the “output” size of the file. If you are using a Webpack plug-in like Uglify, this value will reflect the reduced size of the code.

  • Gzip size: This is the size of the package/module that is parsed through gzip compression.

conclusion

The comments section describes some of the more common configurations, as well as a number of configuration properties. You can see webPack-Bundle-Analyzer in his repository. Overall, it is currently the most intuitive and easily configured to analyze current projects. It’s a great tool to look at when you’re ready to optimize after your project is over.