转译和编译_【webpack 性能优化】编译速度从 50S 到 7S

本篇文章主要记录下一次 webpack 的一次性能优化

现状

随着项目不断发展壮大，组件数量开始变得越来越多，项目也开始变得庞大，webpack 编译的时间也会越来越久，我们现在的项目编译一次在 40s ——70s 之间，这是一个效率非常低下的操作。优化的手段有很多，之前项目原本已经做了很多，本文从缓存的角度进行优化讲解

以下仅介绍几种缓存相关的优化手段，包括

• babel-loader 的 cacheDirectory
• cache-loader
• dll 动态链接库
• HardSourceWebpackPlugin

先说结论，第一个是项目中已有的，第二第三个效果不大，第四个达到了预期的效果

我们的 webpack 版本：4.41.2，系统：mac os

瓶颈分析

优化的第一步，应该是分析目前的性能，这里我们使用 speed-measure-webpack-plugin 进行速度分析

// 安装
npm install --save-dev speed-measure-webpack-plugin

// 使用方式
const SpeedMeasurePlugin = require("speed-measure-webpack-plugin");
 
const smp = new SpeedMeasurePlugin();
 
const webpackConfig = smp.wrap({
     
  plugins: [
    new MyPlugin(),
    new MyOtherPlugin()
  ]
});

结果类似如下，可以看到每一个 Loader 以及 Plugin 的耗时，有了这个，我们就可以“对症下药”

但需要注意的是：HardSourceWebpackPlugin 和 speed-measure-webpack-plugin 不能一起使用，这一点让我郁闷了很久

babel-loader 的 cacheDirectory

babel-loader 允许使用 Babel 和 webpack 转译 JavaScript 文件，有时候如果我们运行 babel-loader 很慢的话，可以考虑确保转译尽可能少的文件。你可能使用 /\.m?js$/ 来匹配，这样有可能去转译 node_modules 目录或者其他不需要的源代码，导致性能下降

可以通过 exclude 排除掉一些不需要编译的文件。比如下面就不会去转义 node_modules 和 bower_components