这是我参与2022首次更文挑战的第1天，活动详情查看：2022首次更文挑战
介绍
相信很多刚入行的小伙伴在做完项目的时候，不知道怎么去性能优化，其实在webpack诞生后很快就出现了很多包可视化分析工具，让我们清晰的看到每个模块的资源占用情况，从而着手去缩减优化。
本期我们将介绍一种webpack可视化分析工具——webpack-bundle-analyzer，我们刚才说了包可视化分析工具很多比如早期的webpack-visualizer-plugin但是它上次发布更新还是在5年前，目前主流的还是webpack-bundle-analyzer，上次更新还是三个月前，而且webpack5也可以正常使用，另外其可视化也比较美观而且更直接看出每个包的资源占比。
如下图：
安装
# NPM
npm install --save-dev webpack-bundle-analyzer
# Yarn
yarn add -D webpack-bundle-analyzer
复制代码使用
当我们安装完毕后，不能不做判断去直接引入，会在诸如jenkins等自动化服务器中部署打包有时候会卡住。因为默认他新开启了server模式，在本地服务开启了一次新服务，而且大多数情况我们基本只会在本地查看分析，所以也没有必要。
我们现在package.json里面写个特定指令专门用来做打包分析吧。如下：
"scripts": {
"build:report": "webpack --mode production --progress",
}
复制代码这里加了一个名叫build:report，回头我们会在只输入这个指令后，再去构建可视化分析。
那么我们如何针对这个指令去处理引入webpack-bundle-analyzer这个webpack插件呢？
pm提供一个名叫npm_lifecycle_event的变量，它可以返回当前正在运行的脚本名称，比如dev、build、test等脚本名。这里我们就可以利用这个变量，在同一个脚本文件里面，区分当前执行的命令。如下：
// 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', // 默认值：server，共有server，static，json，disabled四种模式
analyzerHost: '127.0.0.1', // 默认值：127.0.0.1，在server模式下使用的主机启动HTTP服务器。
analyzerPort: 8888, // 默认值：8888，在server模式下使用的端口号
reportFilename:"report.html", // 默认值：report.html，在static模式下生成的捆绑报告文件的路径名
openAnalyzer:true, // 默认值：true，是否在默认浏览器中自动打开报告
}))
}
module.exports = {
// ...
plugins
}
复制代码目前webpack-bundle-analyzer共有四种模式：
- server模式：分析器将启动 HTTP 服务器以显示捆绑报告。
- static模式：生成带有捆绑报告的单个 HTML 文件。
- json模式：生成带有捆绑报告的单个 JSON 文件。
- disabled模式：生成 Webpack Stats JSON 文件。
现在我们只要运行：
# NPM
npm run build:report
# Yarn
yarn build:report
复制代码就可以自动打开一个本地服务查看分析当前项目的包占用情况了。
这里我们可以移入不同块看到出现各种不同的大小表示：
-
stat size： 原始大小，或者说是文件再未经处理前的大小。
-
parsed size： 这是文件的“输出”大小。如果你使用的是 Uglify 之类的 Webpack 插件，那么这个值将反映代码的缩小后的大小。
-
gzip size： 这是通过 gzip 压缩运行解析的包/模块的大小。
结语
刚才的注释部分是比较常用的一些配置介绍，当然还有很多配置属性，在他的仓库可以看到webpack-bundle-analyzer。总的来说，他是目前最直观，配置也比较方便的可以分析当前项目。是在你的项目结束后准备着手优化时的一把观察利器。