前言

随着前端工程化的开发方式日益完善，像 webpack、rollup、gulp 等工具已经融入到我们的日常开发之中。最常见的就是 webpack ，一个模块打包工具。

但随着项目的功能需求迭代，代码量越来越多，原先构建时没有暴露的问题现在倍数级放大。

我目前的项目首次编译时间达到 43 秒，你是否能想象我们是怎么等待每次的代码修改？

接下来，我将列举 6 种切实可行的高效方案，让整个构建时间由 43 秒降到 4 秒。

优化点排查

你可以查看之前我写过的：

webpack 优化：2 款工具帮你找到构建速度“变慢”的原因

我在这篇文章中分析了是什么导致目前项目构建时间长的原因。

希望你也能借助这两款工具，分析出你项目构建慢的真正原因。

externals 外链第三方依赖

时间：43.8s -> 40.8s

externals 是常用优化手段。构建时，将依赖文件相关从 node_modules 导入改为外部链接引用（即：通过 script 标签，以 CDN 的方式加载）

你可以把常见的 libs 以 CDN 的方式导入，像 vue，react，jquery 等，他们的官方都提供了可靠的 CDN 服务。

externals 外部变量定义

webpack-bundle-analyzer 前后对比

前

后

体积最大的 js 编译后，由 900 kb 降到了 421 kb （大小减了 30%）

替换 css 编译工具

时间：40.8s -> 35.8

用 fast-sass-loader 替换 sass-loader

为什么 fast-sass-loader 那么快？

fast-sass-loader 将 sass 文件扁平化使 node-sass 不会重复编译同个文件，编译前会对所有的文件进行合并，按照一个大文件进行编译，同时内部有 cache 机制针对每个 entry 文件。

同时使用了 fast-sass-loader 就不用使用 resolve-url-loader 来解决 sass-loader 路径引用的问题。

使用 CommonsChunkPlugin 提取公共代码

时间：35.8s -> 27.9

提取后

提取前

提取后

能从上两图看到，重复模块的引用问题得到解决。并且数量大幅降低。

babel-loader 优化

时间：27.9s -> 21.6s

设置 babel-loader 编译过程中需要解析的路径，以及排除 node_modules 相关依赖；

同时加上 cacheDirectory 开启缓存。

开启多线程

时间：21.6s -> 18.3s

使用 happypack plugins ，它将尽可能利用硬件资源，多线程方式来编译代码。

虽说开启多线程会加快编译的速度，但就目前情况而言减少幅度很少，不像网上那么明显。

考虑原因是，基本已经优化的差不多了，代码编译已经瞬时可以完成了，不再需要多线程的帮助了。开启多线程还会增加额外的判断。

优化多页面

时间：21.6s -> 最低 4s

这条因项目而异（可能对你不适用，但我希望能 get 到其中的思想）

由于我们项目是多页面应用，中间使用了 html-webpack-plugin 来做 chunks js 的自动引用，导致这个 html-webpack-plugin 插件会被执行多次（50个chunks ，就会有50次）

我测试过，当注释掉该插件的使用后，整个项目的构建时间大幅降低，所以接下来的构建优化将以此插件为入口。

根据分析，虽然会有多次的该插件的使用，但实际只是其中某个 entry 的参数不同，仅此而已。

社区有解决方案，你可以试下 html-webpack-plugin-for-multihtml，不过即使这样我更想通过简单粗暴的办法来质变它。

我们的业务模块，大体会分为 A，B，C，D，E …，如果今天开发的需求是涉及 A 的，能不能只编译 A 模块相关的 entry 文件呢？假设分了 5 个大类，那么现在只编译其中的一类，连小学生都知道编译时间就是缩短 5 倍。

就这样，我把原先的 entry 做了调整，按需分类：

当我需要 user 用户模块时，只要构建 user 相关的文件就可以了。编译时间大幅降低。

为了将此过程在开发中不繁琐，我针对该项目写了个简单的脚本，当选择好编译模块后，再开始 webpack 构建。

按需构建

如果你有兴趣可以看下 inquirer 模块，当然这不是本文的重点。

总结

通过上面这六板斧，将构建时间降到了最低 4s 。

同时 webpack 构建的优化还有其他方式，我列举几个关键字：

devtool、resolve、cache-loader、Dllplugin、uglify-parallel、hot、webpack upgrade ...

就目前该项目的成绩，基本够用了。希望能让阅读此文的你得到些启发。

关于我

一位“前端工程师”，乐于实践，并分享前端开发经验。

如果有问题或者想法，欢迎各位评论留言，愿大家共同进步。

关注【前端雨爸】，查阅更多前端技术心得。