Webpack 打包速度深度优化：从 25 秒到 7 秒的实践

项目背景与优化目标

近期对项目的本地开发环境执行了打包速度优化。尽管项目中已应用了网上常见的多种优化方案，但在 16 年低配 Mac Pro 上，初始打包时间仍长达 25 秒以上。通过深入调整细节配置，最终将打包时间大幅降低至 7 秒左右。

DLL 预编译与 Babel 配置策略

DLL 预编译配置优化

原有项目线上与本地共用一套 DLL 配置。由于 antd 等 UI 库需要按需加载，无法直接放入 DLL 中。为此，可以单独编写一份 DLL 配置文件，将所有其他第三方库纳入其中，以实现更高效的预编译。

开发环境 Babel 配置调整

由于 .babelrc 中配置的 babel-plugin-import 插件会导致上述 DLL 优化失效，因此需要针对开发环境单独配置 Babel。具体操作是将 options 中的 babelrc 设置为 false，并重新编写一份 Babel 配置。关键在于，这份新配置中绝对不能包含“import”插件。

遇到一个新问题：由于未导入插件，导致所有 antd 组件的样式丢失。解决方法是在 index-template.html 中添加一行注释 <!-- local-style -->，在本地打包时将其替换为对应版本 antd 在 CDN 上的 CSS 文件。

缓存机制与 Babel 升级实践

引入 cache-loader 缓存机制

cache-loader 是处理复杂构建场景的有效工具。尽管 Webpack 配置中存在多种缓存设置选项，但实际测试表明，cache-loader 可以替代其他多数缓存配置。它会在项目中创建 .cache-loader 文件夹，将缓存文件直接写入硬盘。虽然首次打包会因写入磁盘多消耗几秒，但后续构建速度将显著提升。

babel-loader 升级与多线程优化

如前文图示所示，将 babel-loader 升级至 8 版本以上，新的 preset 和 plugin 在命名上有所变化。使用 preset-env 替代以往的 201X 版本预设，并通过 targets 指定目标代码（即编译后代码）的版本。鉴于本地开发环境，可将目标指定为 Chrome 的高版本，这样许多新语法无需转换，从而节省编译时间。在打包速度降至 10 秒以下后，每减少一秒都意味着超过 10% 的性能提升。不过，此方案需谨慎使用，因为可能导致线上与本地环境不一致，进而引发难以排查的 Bug。

移除 Happypack 的性能验证

移除 Happypack 以提升性能

测试过程中发现一个有趣现象：Happypack 反而降低了打包效率。经过反复验证，babel-loader 8+ 似乎已内置多线程优化功能，使得 Happypack 变得多余。相反，Happypack 带来的线程通信反而造成了资源浪费。babel-loader 8+ 的 CPU 使用率及打包时间与“babel-loader 6+ 加 Happypack”方案大致相当，但在 Google 搜索及官网文档中均未见相关说明。既然能提升速度，便直接采用此方案。

总结与后续计划

后续优化计划

该项目代码量为两人迭代一年，基于上述配置，大多数类似项目应可优化至 10 秒左右的打包速度（具体视项目规模而定，20 秒以内均属正常范围）。一些细微的优化细节对整体性能影响较小，故在此忽略。目前项目仍使用 Webpack 3+ 版本，因担心 Webpack 4 的重大变更影响过大，暂未升级。预计升级后仍可获得小幅提速。目前的 7 秒并非极限，预估优化至 5 秒问题不大，后续若需进一步突破，则需更具创意的优化思路。

以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持本站。