当你的应用的规模还很小时，你可能不会在乎Webpack的编译速度，无论使用3.X还是4.X版本，它都足够快，或者说至少没让你等得不耐烦。但跟着业务的增多，嗖嗖嗖一下项目就有上百个组件了，也是件很简单的工作。这时候当你再独立编前端模块的出产包时，或者CI工具中编整个项目的包时，如果Webpackp配置没颠末优化，那编译速度城市慢得一塌糊涂。编译耗时10多秒钟的和编译耗时一两分钟的体验是迥然差此外。出于开发时的表情的考虑，加上不能让我们前真个代码编译拖累整个CI的速度这两个出发点，迫使我们必需去加快编译速度。本文主要是探讨下可做编译速度优化的处所，对一些API使用上不会做太多讲解，需要的同学可以直接翻看文档中的介绍。笔者的Webpack版本为4.29.6，后文中内容都基于这个版本。

一、已存在的针对编译速度的优化

笔者这套Webpack架子源自CRA的eject，基于Webpack4.x，在Loader和Plugin的选择和设计上已是最佳实践方案，根基上无需窜改什么。其原有的对编译的优化配置在于这三处：

1. 通过terser-webpack-plugin的parallel和cache配置来并行措置惩罚惩罚并缓存之前的编译功效。terser-webpack-plugin是之前UglifyPlugin的一个替代品，因为UglifyPlugin已经没有继续维护了，从Webpack4.x起，已经保举使用terser-webpack-plugin来进行代码压缩、混淆，以及Dead Code Elimination以实现Tree Shaking。对付parallel从整个设置的名称大家就会知道它有什么用，没错，就是并行，而cache也就是缓存该插件的措置惩罚惩罚功效，不才一次的编译中对付内容未转变的文件可以直接复用上一次编译的功效。

2. 通过babel-loader的cache配置来缓存babel的编译功效。

3. 通过IgnorePlugin设置对moment的整个locale本地化文件夹导入的正则匹配，来防备将所有的本地化文件进行打包。如果你确实需要某国语言，仅手动导入那国的语言包即可。

在项目逐渐变大的过程中，出产包的编译时间也从十几秒增长到了一分多钟，这是让人受不了的，这就迫使着笔者必需进行特别的优化以加快编译速度，为编包节省时间。下面的段落就讲解下笔者做的几个特别优化。

二、多线程（进程）撑持

从上个段落的terser-webpack-plugin的parallel设置中，我们可以得到这个启发：启用多进程来模拟多线程，并行措置惩罚惩罚资源的编译。于是笔者引入了HappyPack，笔者之前的那套老架子也用了它，但之前没写对象来介绍那套架子，这里就一并说了。关于HappyPack，经常玩Webpack的同学应该不会陌生，网上也有一些关于其道理的介绍文章，也写得很不错。HappyPack的事情道理大抵就是在Webpack和Loader之间多加了一层，改成了Webpack并不是直接去和某个Loader进行事情，而是Webpack test到了需要编译的某个类型的资源模块后，将该资源的措置惩罚惩罚任务交给了HappyPack，再由HappyPack复兴内部进行线程调理，分配一个线程挪用措置惩罚惩罚该类型资源的Loader来措置惩罚惩罚这个资源，完成后上报措置惩罚惩罚功效，最后HappyPack把措置惩罚惩罚功效返回给Webpack，最后由Webpack输出到目的路径。将都在一个线程内的事情，分配到了差此外线程中并行措置惩罚惩罚。

使用要领如下：

首先引入HappyPack并创建线程池：

const HappyPack = require(‘happypack‘); const happyThreadPool = HappyPack.ThreadPool({size: require(‘os‘).cpus().length - 1});

替换之前的Loader为HappyPack的插件：

{ test: /\.(js|mjs|jsx|ts|tsx)$/, include: paths.appSrc, use: [‘happypack/loader?id=babel-application-js‘], },

将原Loader中的配置，移动到对应插件中：

new HappyPack({ id: ‘babel-application-js‘, threadPool: happyThreadPool, verbose: true, loaders: [ { loader: require.resolve(‘babel-loader‘), options: { ...省略 }, }, ], }),

大抵使用方法如上所示，HappyPack的配置讲解文章有很多，不会配的同学可以本身搜索，本文这里只是顺带说说而已。

HappyPack老早也没有维护了，它对url-loader的措置惩罚惩罚是有问题的，会导致颠末url-loader措置惩罚惩罚的图片都无效，笔者之前也去提过一个Issue，有另外开发者也发明过这个问题。总之，用的时候必然要测试一下。

对付多线程的优势，我们举个例子：
好比我们有四个任务，定名为A、B、C、D。

任务A：耗时5秒

任务B：耗时7秒

任务C：耗时4秒

任务D：耗时6秒

单线程串行措置惩罚惩罚的总耗时约莫在22秒。

改成多线程并行措置惩罚惩罚后，总耗时约莫在7秒，也就是阿谁最耗时的任务B的执行时长，仅仅通过配置多线程措置惩罚惩罚我们就能得到大幅的编译速度提升。