前端项目构建速度优化调研

一、分析工具

webpackbar

统计打包进度，这个功能可有可无，不过提供了一个比较好的能力，就是上报能力，我们后面如果想统计打包时间的话，可以考虑从这里入手。

speed-measure-webpack-plugin

webpack-bundle-analyzer

二、worker pool 加速 loader

happypack 和 thread-loader

开启单独的 worker 池，都是加速 loader 的处理过程。happypack 已经没有更新了。而且两者都需要对 loader 的深度定制，不太适合作为公共能力，更适合针对单个项目做优化。

比如使用 thread-loader 需要放在所有 loader 的前面。

module.exports = {
  module: {
    rules: [
      {
        test: /\.js$/,
        include: path.resolve("src"),
        use: ["thread-loader", "expensive-loader"],
      },
    ],
  },
};

三、缓存提速二次构建

比如 babel-loader 和 terser-webpack-plugin 这些已经有自带的缓存逻辑了。缓存的内容就在 /node_modules/.cache中，删掉之后构建时间达到 185.85s 。

babel-loader 和 terser-webpack-plugin 是耗时的重点部分。

cache-loader

在一些性能开销较大的 loader 之前添加此 loader，以将结果缓存到磁盘里。

同上，webpack 官方提供的优化能力，更适合单独的定制优化，不适合公共能力。

module.exports = {
  module: {
    rules: [
      {
        test: /\.ext$/,
        use: ["cache-loader", ...loaders],
        include: path.resolve("src"),
      },
    ],
  },
};

⚠️ 请注意，保存和读取这些缓存文件会有一些时间开销，所以请只对性能开销较大的 loader 使用此 loader。

hard-source-webpack-plugin

同样已经很久没有维护了。可以从上面表格中看到确实有一些效果，第二次构建。63s -> 44s。

但是如果把 /node_modules/.cahce 文件删掉，会发现构建时间大大增加耗时 1min35s，这种情况下，第二次的构建的效果不好，不推荐使用。

四、动态链接

核心思路就是针对引入的第三方库不重复构建。个人考虑还是比较适用于针对项目级别的优化，不太适合作为公共能力的优化。

如果要做的话，个人思路，我们的插件去检测当前项目引入的第三方库，然后去分析引入的第三方库的打包大小？动态分析出来要单独打包的文件？然后按照一定的阈值，将大于此阈值的项目作为不重复构建的部分。需要在用户 webpack 配置和最终输出的 webpack 中间加一层处理。

需要考虑几个问题：
- 满足什么情况的时候重新构建 dll，比如 package.json 中引入的第三方库版本发生变化
- 如何动态分析哪些文件需要单独打包 dll

五、build 文件体积

没有太多发挥的空间，大部分脚手架创建的项目自带代码压缩插件，这部分发挥空间不大。

六、esbuild & SWC

vite 开发环境的构建工具。vite 官方文档：https://cn.vitejs.dev/guide/why.html#why-bundle-for-production

为何不用 ESBuild 打包？虽然 esbuild 快得惊人，并且已经是一个在构建库方面比较出色的工具，但一些针对构建应用的重要功能仍然还在持续开发中 —— 特别是代码分割和 CSS 处理方面。就目前来说，Rollup 在应用打包方面更加成熟和灵活。尽管如此，当未来这些功能稳定后，我们也不排除使用 esbuild 作为生产构建器的可能。