【译】Google - 使用 webpack 进行 web 性能优化（三）：监控和分析应用

时间 2019-11-06

标签 google 使用 webpack 进行 web 性能优化监控分析应用栏目 Google 繁體版

原文原文链接

原文地址： monitor and analyze

原文做者： Ivan Akulov

译文地址： 监控和分析应用

译者： 泥坤

校对者： 杨建、闫蒙

即便你能够经过配置 webpack 使得应用尽量小，追踪它而且知道它包含什么仍然是很重要的。不然，你可能安装了一个让应用大了两倍的依赖却浑然不觉。react

这节就来说几个能够帮助你深刻分析 bundle 的工具。webpack

追踪 bundle 的大小

为了监控你的应用大小，能够在开发过程当中使用 webpack-dashboard 和在 CI 上使用 bundlesize。git

webpack-dashboard

webpack-dashboard 加强了 webpack 的输出，包含依赖的大小、进度和其余细节。这是它的界面：github

这个看板帮助追踪大的依赖 —— 若是你增长了一个依赖，那么你就可以马上在 Modules 部分中看到它。web

要想使用它，须要安装依赖包 webpack-dashboard :express

npm install webpack-dashboard --save-dev
复制代码

而后在 webpack.config.js 文件中的 plugins 字段里增长这个 plugin:npm

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

module.exports = {
  plugins: [
    new DashboardPlugin(),
  ],
};
复制代码

若是你使用基于 express 的服务，也可使用 compiler.apply():json

compiler.apply(new DashboardPlugin());
复制代码

尽情地使用 dashboard 来找到可能优化的地方吧！举个例子，纵览 Modules 部分能够找到过大的库，而后用相对小的库来替代掉它。浏览器

bundlesize

bundlesize 校验 webpack 的资源有没有超过指定的大小。将它集成到 CI 中，就能够在应用过大的时候收到提醒。缓存

配置:

肯定大小上限

先优化应用，让它尽量小，而后运行生产环境构建；

在 package.json 中增长 bundlesize 字段的配置，以下：

// package.json
{
  "bundlesize": [
    {
      "path": "./dist/*"
    }
  ]
}
复制代码

用 npx 执行 bundlesize:

npx bundlesize
复制代码

将打印出每一个文件 gzip 事后的大小

PASS  ./dist/icon256.6168aaac8461862eab7a.png: 10.89KB
PASS  ./dist/icon512.c3e073a4100bd0c28a86.png: 13.1KB
PASS  ./dist/main.0c8b617dfc40c2827ae3.js: 16.28KB
PASS  ./dist/vendor.ff9f7ea865884e6a84c8.js: 31.49KB
复制代码

在每一个文件大小的基础上增长 10-20%，就能够获得大小上限。这 10%-20% 的 buffer 能够保证既不妨碍你平常开发，又能够在它的体积增加过快的时候向你报警。

启用 bundlesize

安装 bunlesize 包做为开发依赖:

npm install bundlesize --save-dev
复制代码

在 package.json 的 bundlesize 字段里，指定具体的大小上限，对于有的文件（例如图片），你可能须要为特定的文件类型设置上限，而不是每一个文件。

// package.json
{
  "bundlesize": [
    {
      "path": "./dist/*.png",
      "maxSize": "16 kB",
    },
    {
      "path": "./dist/main.*.js",
      "maxSize": "20 kB",
    },
    {
      "path": "./dist/vendor.*.js",
      "maxSize": "35 kB",
    }
  ]
}
复制代码

增长 npm 脚原本运行检查。

// package.json
{
  "scripts": {
    "check-size": "bundlesize"
  }
}
复制代码

配置好 CI ，以便在每次 push 的时候运行 npm run check-size （若是你在 github 上开发项目的话还能够在 github 中集成 bundlesize)。

就是这样！如今若是你运行 npm run check-size 或者 push 代码，你会看到输出文件是否足够小。

若是是失败的状况：

扩展阅读:

Alex Russell 关于现实世界中咱们应该追求的加载时间

分析 bundle 为何这么大

你可能想要深刻研究 bundle，来分析哪些模块占用了空间。请看 webpack-bundle-analyzer:

(Screen recording from github.com/webpack-con…)

webpack-bundle-analyzer 扫描 bundle 而且创建一个可视化的结果展现它包含什么，经过该可视化界面能够去找大的或者没必要要的依赖。

要使用 analyzer，须要安装 webpack-bundle-analyzer。

npm install webpack-bundle-analyzer --save-dev
复制代码

在 webpack 配置文件里增长一个 plugin。

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

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

而后运行 production build，插件会在浏览器里打开一个统计的页面。

默认状况下，统计页面展现的是解析事后的文件大小。（即出如今 bundle 里的文件），你可能想要比较 gzip 压缩以后的大小，由于这会更接近真实用户的体验。能够在侧边栏切换大小类型。

⭐️注意 : 若是你使用 ModuleConcatenationPlugin，一部分在 webpack-bundle-analyzer 输出的模块可能会被合并，使得报告的信息量减小。因此若是你在用这个插件，在分析的过程当中须要将它禁用掉。

如下是但愿从报告中获得的信息：

大的依赖 为何他们那么大？是否有更小的替代品（例如 Preact 代替 React）？你是否须要其中的所有代码？（例如，Moment.js 包含不少并不常使用并能够扔掉的本地化语言环境）
重复的依赖 你是否在多个文件里看到相同的依赖？（使用像 webpack4 中的 optimization.splitChunks.chunks 选项或者 webpack3 中的 CommonsChunkPlugin 来将他们移到一个公共文件里）或者 bundle 是否包含了同一个库的多个版本？
类似的依赖 是否有类似的库作着差很少的事情？（例如 comment 和 date-fns 或者 lodash 和 lodash-es）试着统一成单一的工具。

同时，建议看一下 Sean Larkin 的 great analysis of webpack bundles。

总结

使用 webpack-dashboard 和 bundlesize 来持续关注你的应用大小。
用 webpack-bundle-analyzer 来深究应用大小的构成

结论

原文地址： conclusion

原文做者： Ivan Akulov

译文地址： 结论

译者： 闫萌

校对者： 周文康、杨建

总结:

减小没必要要的字节。 压缩全部资源，去除无用代码，谨慎添加依赖。
经过路由分离代码。 只加载当前真正须要的资源，其余的资源延迟加载。
缓存代码。 应用中某部分代码的更新频率比其余部分低。能够将这部分代码剥离，以便只在必要时从新加载。
持续关注应用大小。 使用像 webpack-dashboard 和 webpack-bundle-analyzer 这类的工具来了解应用的大小。而后每隔几个月从新检查一下应用的性能。

Webpack 不是惟一一个能够帮助你让应用变得更快的工具。还能够考虑让你的应用变成一个渐进式 web 应用（Progressive Web App），从而得到更好的体验，而且使用像 Lighthouse 这样的自动分析工具来得到改进意见。

别忘了去阅读 webpack 文档 - 那里还有大量有用的信息。

同时记得用 training 项目来练习哦！