由于维护 [umi](https://github.com/umijs/umi/) 和 [roadhog](https://github.com/sorrycc/roadhog)，最近有收到不少关于 webpack 构建慢的咨询，比如 dev 启动慢，热更新慢，构建需要 30 分钟，内存爆掉等等，花了些时间查资料和实践，整理如下，供参考。

dev 和 build 有不同的优化方式。因为 dev 可不考虑加载问题，所以可以提前多编译一些，并且可以有缓存，所以二次编译会快很多；而 build 下主要的问题还是 uglify 的问题。

## dev

### dll (动态链接库)

node_modules 下的模块通常不会变，除非安装了新的依赖或者修改了依赖的版本，dll 是提前构建好一个包含指定模块（通常是所有依赖）并提供一个 manifest 提供模块信息，然后启动 dev 时根据这份 manifest，既有的模块就无需重新构建，通常能减少 30%~50% 的启动时间。

缺点是配置起来比较麻烦，比如：

* 需要做两次构建
* 在需要的时候（依赖有修改）重新构建 dll
* 在 html 里引入提前构建好的 dll 脚本

如果你使用 [umi](https://github.com/umijs/umi/)，那么这些事情通过 [umi-plugin-dll](https://github.com/umijs/umi/tree/master/packages/umi-plugin-dll) 全部自动处理了。

### [hard-source-webpack-plugin](https://github.com/mzgoddard/hard-source-webpack-plugin)

这是我最近发现的库，简直神器，让我觉得按需编译都没啥必要做了，以 [antd-pro](https://github.com/ant-design/ant-design-pro) 为例，使用此插件之后，二次启动时[仅需 11s](https://gw.alipayobjects.com/zos/rmsportal/exlNLjwvJXUvTXVlPQDK.png) 。

原理是啥？webpack 的递增编译是很快的，为啥？因为有缓存。所以这个插件实际上是把这部分的缓存保存到物理文件，二次启动时从缓存里读取，所以只需要做递增编译即可。

umi 和 roadhog 的最新版本已内置，大家可以感受下。有遇到问题的可以通过环境变量 `HARD_SOURCE=none` 关闭，目前已知有：

* [Invalid string length](https://github.com/mzgoddard/hard-source-webpack-plugin/issues/274)
* [某些场景下 cpu 暴涨，但我这不能重新](https://github.com/sorrycc/roadhog/issues/710)

### [cache-loader](https://github.com/webpack-contrib/cache-loader)

应该和上面的功能类似，经测试，效果不明显。以 umi-examples/with-dva 为例，不加 cache-loader 12s，加了 11s。

### [thread-loader](https://github.com/webpack-contrib/thread-loader)

CRA 里加在，但我测过发现反而慢了。以 umi-examples/with-dva 为例，不加 thread-loader 12s，加了 13s。

### 按需编译（不是按需加载）

假设我们有 100 个页面，而 SPA 通常只有一个 entry，所以就算我们只需调试一个页面，也需要把这 100 个页面都编译一遍。这！完全不合理嘛！所以就有了按需编译，最早是在 next.js 里看到，然后我把他应用到 umi 里，实现方式有所不同。

原理其实很简单，根据 url 的访问来判断出需要加载哪些页面（路由），然后把这些路由编译了。

## build

### uglify 问题

uglify 即代码压缩，有两个问题，1 是慢，2 是内存消耗高，一些大的项目 8G 甚至 16G 内存都不够用。而像 parcel、webpack@4 发布时所说的速度提升，通常都是抛开了 uglify 而言的。

uglify 所需的时间只和依赖文件的大小多少有关，比如依赖了一个图形库，通常就很慢很慢了。

那么怎么办？按我的理解，有两个办法：

1. 减少依赖文件
2. 减少需要压缩的文件

减少依赖文件有不少办法，比如：

1. 优化 common 提取策略，让整体尺寸尽可能少
2. externals 掉一些大的库，降低整体尺寸
3. 利用 webpack 的 tree shake + es module，排除掉一些没有用到的模块
4. ...

### common 提取策略

common 提取即利用 webpack.optimize.CommonsChunkPlugin 提取公共部分，而如何提取需要根据自己的项目需要决定。

我理解 common 提取有两个极端，

1. 被两个 entry/page 依赖即提取为公共，这样 common 会比较大，整体尺寸最小，但加载首个页面时需要下载的尺寸会比较大
2. 被所有 entry/page 依赖才提取为公共，这样 common 比较小，整体尺寸较大

目前 umi 和 next.js 都是采用折中的方案，即被一半 entry/page 依赖才提取为公共。这是通用的解，但不是最优解。具体如何提取，可以视项目需要自行决定。

### externals

externals 是非常有效的一个方案，可以一下子减少大量需要编译、压缩的模块。

比如配置：

externals: { react: 'window.React' }

然后在 html 里引入 react.js，这样 react 就不用解析了。

比较极端的是我们把所有模块都 externals 掉，这样只需要编译项目文件（支付宝小程序是这么做的），所以速度就会很快。

但是会带来的问题是：

1. 无法利用 webpack 的 tree-shake
1. 多个库之间如果存在公共模块（比如 lodash），就无法复用

这样子，实际上用户访问时需要下载的文件就会增加。

另外，使用 externals 的一个麻烦的地方就是你需要在 html 里引用额外的 js 文件，这里也有几个潜在的问题：

1. 如果你的 cdn 不支持 combo，并且不是 http/2，那么速度会慢
2. 你需要手动维护一份 cdn 文件列表，并且跟进他们的更新，也是件麻烦的事情

而这些麻烦的事情，umi 会计划帮你做掉，请期待后续 umi 的方案。

### uglify 的 exclude 参数

### uglify-webpack-plugin

https://github.com/umijs/umi/pull/418

### [webpack-parallel-uglify-plugin](https://github.com/gdborton/webpack-parallel-uglify-plugin)

## 通用

### sourcemap

### 依赖分析

## 其他

* happypack
* parcel

## 参考：

* https://github.com/webpack/webpack/issues/250#issuecomment-240643985
* https://medium.com/ottofellercom/0-100-in-two-seconds-speed-up-webpack-465de691ed4a
* https://blog.box.com/blog/how-we-improved-webpack-build-performance-95/
* https://github.com/jmblog/how-to-optimize-momentjs-with-webpack
* https://github.com/webpack/docs/wiki/build-performance