Webpack 性能优化二次编译速度提升3倍！

本文作者为 360 奇舞团前端开发工程师 Rien.

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

现状

随着业务复杂度的不断增加，项目也开始变得庞大，工程模块的体积也不断增加，webpack 编译的时间也会越来越久，我们现在的项目二次编译的时间在 5s到6s 之间，对于我们迭代速度非常快的项目来说，二次编译时间长会导致效率非常低下。优化的手段有很多，之前项目原本已经做了很多如环境分离、并行编译等优化，本文从几个小的角度进行二次编译的优化讲解，大家也可以检查一下自己的项目能否从以下几个方面进行优化。

更改source map配置

首先，介绍一款插件webpack.ProgressPlugin。官网给出的解释是

The ProgressPlugin provides a way to customize how progress is reported during a compilation.

也就是说，ProgressPlugin可以监控各个hook执行的进度，输出各个hook的名称和描述，输出构建进度。通过插件webpack.ProgressPlugin对webpack整个运行做了分析，发现耗时较长的阶段主要是生成sourceMap文件的阶段：

通过查阅sourcemap的配置，发现了问题是因为devtool配置为source-map的原因。之前的同学使用source-map可能是因为要做一些其他的处理，需要用到源码，现在并无此需要。Webpack支持sourceMap20+种不同的方式，通过关键字组合，可以生成用于各种场景的sourcemap。每种方式的速度和效果各不相同。效果最好的速度最慢。

在这里我贴了一张官网截图的对比图：

从上图我们可以看到webpack为sourcemap提供的一些关键字，而sourcemap模式都是左边介绍的关键字进行拼接构成。

上图是一些不同配置项的对比，可以看到其中一些值适用于开发环境，一些适用于生产环境。

对于开发环境，通常希望更快速的sourcemap，需要添加到bundle中以增加体积为代价，但是对于生产环境，则希望更精准的sourcemap，需要从bundle中分离并独立存在。在开发环境下使用eval-cheap-module-source-map（webpack推荐方式）大大减少了这一阶段的耗时，同时对开发体验及错位定位影响较小。

这里顺便提一下，生产模式我们可以使用：none，因为SourceMap会暴露源代码；调试是开发阶段的事情。如果对代码实在没有信心可以使用nosources-source-map。 sourcemap里是有sourceContent部分的，也就是直接把源码贴在这里，这样的好处是根据文件路径查不到文件也可以映射，但这样会增加sourcemap的体积，也会暴露源码。加上 nosources之后，生成的sourcemap就没有sourceContent部分了，sourcemap文件大小会小很多，也不会暴露源码。

Html-webpack-plugin的升级

经过上面的优化二次编译的时间有了较大的提升。但是通过观察分析，发现html-webpack-plugin耗时不太正常，因为html-webpack-plugin 的作用很简单，就是：使用 webpack打包时创建一个 html 文件，并把 webpack 打包后的静态文件自动插入到这个 html 文件当中。我们已经从全量的8个页面改为增量单个html启动了耗时不应该那么久。

经过排查及github issue里看到，是当前插件版本有一些性能问题。