带你深度解锁Webpack系列(基础篇)和带你深度解锁Webpack系列(进阶篇)，主要是讲解了 Webpack 的配置，但是随着项目越来越大，构建速度可能会越来越慢，构建出来的js的体积也越来越大，此时就需要对配置进行优化。
文中罗列出了十多种优化方式，大家可以结合自己的项目，选择适当的方式进行优化。这些 Webpack 插件的源码我大多也没有看过，主要是结合 Webpack 官方文档以及项目实践，在验证后输出了本文，如果文中有错误的地方，欢迎在评论区指正。
鉴于前端技术变更迅速，祭出本篇文章基于 Webpack 的版本号:
├── [email protected]
└── [email protected] 本文对应的项目地址(编写本文时使用)供参考：https://github.com/YvetteLau/...
量化
有时，我们以为的优化是负优化，这时，如果有一个量化的指标可以看出前后对比，那将会是再好不过的一件事。
speed-measure-webpack-plugin 插件可以测量各个插件和loader所花费的时间，使用之后，构建时，会得到类似下面这样的信息：
对比前后的信息，来确定优化的效果。
speed-measure-webpack-plugin 的使用很简单，可以直接用其来包裹 Webpack 的配置:
//webpack.config.js
const SpeedMeasurePlugin = require("speed-measure-webpack-plugin");
const smp = new SpeedMeasurePlugin();
const config = {
//...webpack配置
}
module.exports = smp.wrap(config);1.exclude/include
我们可以通过 exclude、include 配置来确保转译尽可能少的文件。顾名思义，exclude 指定要排除的文件，include 指定要包含的文件。
exclude 的优先级高于 include，在 include 和 exclude 中使用绝对路径数组，尽量避免 exclude，更倾向于使用 include。
//webpack.config.js
const path = require('path');
module.exports = {
//...
module: {
rules: [
{
test: /\.js[x]?$/,
use: ['babel-loader'],
include: [path.resolve(__dirname, 'src')]
}
]
},
}下图是我未配置 include 和配置了 include 的构建结果对比：
2. cache-loader
在一些性能开销较大的 loader 之前添加 cache-loader，将结果缓存中磁盘中。默认保存在 node_modueles/.cache/cache-loader 目录下。
首先安装依赖：
npm install cache-loader -Dcache-loader 的配置很简单，放在其他 loader 之前即可。修改Webpack 的配置如下:
module.exports = {
//...
module: {
//我的项目中,babel-loader耗时比较长，所以我给它配置了`cache-loader`
rules: [
{
test: /\.jsx?$/,
use: ['cache-loader','babel-loader']
}
]
}
}如果你跟我一样，只打算给 babel-loader 配置 cache 的话，也可以不使用 cache-loader，给 babel-loader 增加选项 cacheDirectory。
cacheDirectory：默认值为 false。当有设置时，指定的目录将用来缓存 loader 的执行结果。之后的 Webpack 构建，将会尝试读取缓存，来避免在每次执行时，可能产生的、高性能消耗的 Babel 重新编译过程。设置空值或者 true 的话，使用默认缓存目录：node_modules/.cache/babel-loader。开启 babel-loader的缓存和配置 cache-loader，我比对了下，构建时间很接近。
3.happypack
由于有大量文件需要解析和处理，构建是文件读写和计算密集型的操作，特别是当文件数量变多后，Webpack 构建慢的问题会显得严重。文件读写和计算操作是无法避免的，那能不能让 Webpack 同一时刻处理多个任务，发挥多核 CPU 电脑的威力，以提升构建速度呢？
HappyPack 就能让 Webpack 做到这点，它把任务分解给多个子进程去并发的执行，子进程处理完后再把结果发送给主进程。
首先需要安装 happypack:
npm install happypack -D修改配置文件:
const Happypack = require('happypack');
module.exports = {
//...
module: {
rules: [
{
test: /\.js[x]?$/,
use: 'Happypack/loader?id=js',
include: [path.resolve(__dirname, 'src')]
},
{
test: /\.css$/,
use: 'Happypack/loader?id=css',
include: [
path.resolve(__dirname, 'src'),
path.resolve(__dirname, 'node_modules', 'bootstrap', 'dist')
]
},
{
test: /\.(png|jpg|gif|jpeg|webp|svg|eot|ttf|woff|woff2|.gexf)$/,
use: 'Happypack/loader?id=file',
include: [
path.resolve(__dirname, 'src'),
path.resolve(__dirname, 'public'),
path.resolve(__dirname, 'node_modules', 'bootstrap', 'dist')
]
}
]
},
plugins: [
new Happypack({
id: 'js', //和rule中的id=js对应
//将之前 rule 中的 loader 在此配置
use: ['babel-loader'] //必须是数组
}),
new Happypack({
id: 'css',//和rule中的id=css对应
use: ['style-loader', 'css-loader','postcss-loader'],
}),
new Happypack({
id: 'file', //和rule中的id=file对应
use: [{
loader: 'url-loader',
options: {
limit: 10240 //10K
}
}],
}),
]
}happypack 默认开启 CPU核数 - 1 个进程，当然，我们也可以传递 threads 给 Happypack。
说明：当 postcss-loader 配置在 Happypack 中，必须要在项目中创建 postcss.config.js。
//postcss.config.js
module.exports = {
plugins: [
require('autoprefixer')()
]
}否则，会抛出错误: Error: No PostCSS Config found
另外，当你的项目不是很复杂时，不需要配置 happypack，因为进程的分配和管理也需要时间，并不能有效提升构建速度，甚至会变慢。
4.thread-loader
除了使用 Happypack 外，我们也可以使用 thread-loader ，把 thread-loader 放置在其它 loader 之前，那么放置在这个 loader 之后的 loader 就会在一个单独的 worker 池中运行。
在 worker 池(worker pool)中运行的 loader 是受到限制的。例如：
- 这些
loader不能产生新的文件。 - 这些
loader不能使用定制的loaderAPI（也就是说，通过插件）。 - 这些
loader无法获取webpack的选项设置。
首先安装依赖：
npm install thread-loader -D修改配置:
module.exports = {
module: {
//我的项目中,babel-loader耗时比较长，所以我给它配置 thread-loader
rules: [
{
test: /\.jsx?$/,
use: ['thread-loader', 'cache-loader', 'babel-loader']
}
]
}
}thread-loader 和 Happypack 我对比了一下，构建时间基本没什么差别。不过 thread-loader 配置起来为简单。
5.开启 JS 多进程压缩
虽然很多 webpack 优化的文章上会提及多进程压缩的优化，不管是 webpack-parallel-uglify-plugin 或者是 uglifyjs-webpack-plugin 配置 parallel。不过这里我要说一句，没必要单独安装这些插件，它们并不会让你的 Webpack 更快。
因为当前 Webpack 默认使用的是 TerserWebpackPlugin，默认开启了多进程和缓存，构建时，你的项目中可以看到 terser 的缓存文件 node_modules/.cache/terser-webpack-plugin。
6.HardSourceWebpackPlugin
HardSourceWebpackPlugin 为模块提供中间缓存，缓存默认的存放路径是: node_modules/.cache/hard-source。
配置 hard-source-webpack-plugin，首次构建时间没有太大变化，但是第二次开始，构建时间大约可以节约 80%。
首先安装依赖:
npm install hard-source-webpack-plugin -D修改 webpack 的配置：
//webpack.config.js
var HardSourceWebpackPlugin = require('hard-source-webpack-plugin');
module.exports = {
//...
plugins: [
new HardSourceWebpackPlugin()
]
}
用另外一个比较大的项目测试了下，配置了 HardSourceWebpackPlugin，构建时间从 8S 左右降到了 2S 左右。
HardSourceWebpackPlugin文档中 列出了一些你可能会遇到的问题以及如何解决，例如热更新失效，或者某些配置不生效等。
7.noParse
如果一些第三方模块没有AMD/CommonJS规范版本，可以使用 noParse 来标识这个模块，这样 webpack 会引入这些模块，但是不进行转化和解析，从而提升 webpack 的构建性能 ，例如：jquery 、lodash。
noParse 属性的值是一个正则表达式或者是一个 function。
//webpack.config.js
module.exports = {
//...
module: {
noParse: /jquery|lodash/
}
}我当前的 webpack-optimize 项目中，没有使用 jquery 或者是 lodash。
因此新建一个项目测试，只引入 jquery 和 loadsh，然后配置 noParse 和不配置 noParse，分别构建比对时间。
配置noParse 前，构建需要 2392ms。配置了 noParse 之后，构建需要 1613ms。 如果你使用到了不需要解析的第三方依赖，那么配置 noParse 很显然是一定会起到优化作用的。
8.resolve
resolve 配置 webpack 如何寻找模块所对应的文件。假设我们确定模块都从根目录下的 node_modules 中查找，我们可以配置:
//webpack.config.js
const path = require('path');
module.exports = {
//...
resolve: {
modules: [path.resolve(__dirname, 'node_modules')],
}
}需要记住的是，如果你配置了上述的 resolve.moudles ，可能会出现问题，例如，你的依赖中还存在 node_modules 目录，那么就会出现，对应的文件明明在，但是却提示找不到。因此呢，个人不推荐配置这个。如果其他同事不熟悉这个配置，遇到这个问题时，会摸不着头脑。
另外，resolve 的 extensions 配置，默认是 ['.js', '.json']，如果你要对它进行配置，记住将频率最高的后缀放在第一位，并且控制列表的长度，以减少尝试次数。
本项目较小，因此测试时，此处优化效果不明显。
9.IgnorePlugin
webpack 的内置插件，作用是忽略第三方包指定目录。
例如: moment (2.24.0版本) 会将所有本地化内容和核心功能一起打包，我们就可以使用 IgnorePlugin 在打包时忽略本地化内容。
//webpack.config.js
module.exports = {
//...
plugins: [
//忽略 moment 下的 ./locale 目录
new webpack.IgnorePlugin(/^\.\/locale$/, /moment$/)
]
}在使用的时候，如果我们需要指定语言，那么需要我们手动的去引入语言包，例如，引入中文语言包:
import moment from 'moment';
import 'moment/locale/zh-cn';// 手动引入index.js 中只引入 moment，打包出来的 bundle.js 大小为 263KB，如果配置了 IgnorePlugin，单独引入 moment/locale/zh-cn，构建出来的包大小为 55KB。
10.externals
我们可以将一些JS文件存储在 CDN 上(减少 Webpack打包出来的 js 体积)，在 index.html 中通过