1. 先搞清楚项目到底慢在哪构建耗时画像与瓶颈定位接手过几个老项目的构建优化我发现一个特别有意思的现象大部分人说Webpack打包太慢的时候其实根本说不清慢在哪个环节。有人一上来就装thread-loader结果构建时间没降多少反而因为进程通信开销把简单的项目搞得更慢有人盲目开cache-loader缓存命中率低得可怜磁盘空间倒是占了不少。我自己的习惯是动任何优化手段之前先花十分钟做一次完整的构建耗时画像。这一步不做后面的所有优化都是猜。1.1 用speed-measure-webpack-plugin生成初始基线speed-measure-webpack-pluginSMP是分析Webpack各阶段耗时最直接的工具接入方式很简单const SpeedMeasurePlugin require(speed-measure-webpack-plugin); const smp new SpeedMeasurePlugin(); module.exports smp.wrap({ // 你的原有webpack配置 module: { rules: [] }, plugins: [] });跑一次构建控制台会输出每个loader和plugin的耗时排行。我拿一个实际项目举例这是典型的输出结构处理环节耗时占比babel-loader编译JS42.3s38%css-loader style-loader12.8s11%eslint-loader检查9.5s8%terser压缩21.6s19%module resolve10.2s9%在这个例子里babel-loader和terser两项加一起占了将近六成时间这才是优化的主战场。至于resolve阶段那10秒可能改一个配置就省下来了优先级反而不高。1.2 别只看总耗时要区分dev和build两个场景很多人犯的第二个错误是混着谈构建优化。开发模式的痛点是冷启动慢和热更新慢生产构建的痛点是压缩慢和分包不合理。两者优化的手段虽然有重叠但优先级完全不同。开发模式下我关心的核心指标是首次编译时间冷启动——决定你打开项目后要等多久才能开始干活文件修改后的增量编译时间——决定你改一行代码后多久能看到效果热更新HMR是否稳定——决定你需不需要手动刷新页面生产模式下我关心的是总构建时间——决定发版的等待成本产物体积和分包情况——决定用户首次访问的加载体验代码压缩的耗时占比——决定构建流水线是不是卡在这一个点上所以我建议先建立一张清单明确你要优化的是哪个场景再针对性地下手。结合我自己的经验大部分团队真正痛的是开发模式的冷启动和增量编译生产模式的耗时反而因为CI机器配置更高、可以接受。把有限的优化精力花在最痛的地方收益才最大。2. Loader、Resolve、Plugin三个高频瓶颈的削减方案定位到瓶颈之后接下来就是具体怎么削。我按Loader、Resolve、Plugin三块来拆每一块都有一些改完立刻见效的配置也有一些需要谨慎对待的坑。2.1 Loader端include/exclude是性价比最高的优化babel-loader之所以慢是因为它默认会对所有通过resolve规则进来的JS文件都做转译包括node_modules里的第三方代码。但实际上node_modules里的包绝大多数都已经发布成了ES5或者提供了构建好的产物根本不需要再过一遍Babel。{ test: /\.(js|mjs|jsx)$/, exclude: /node_modules/, use: { loader: babel-loader, options: { cacheDirectory: true, cacheCompression: false, } } }exclude: /node_modules/是我见过收益最高、风险最低的一项配置。很多项目没写这个等于白白让Babel多编译了几千个模块。加上之后冷启动时间普遍能降20%到30%。这里有个容易被忽略的小细节cacheCompression在开发模式下建议设为false。它的作用是决定缓存的产物是否压缩。压缩能省磁盘空间但写入和读取都要额外消耗CPU。开发模式的机器一般不缺那点磁盘关掉压缩能让第二次构建的加载速度快不少。如果项目里用了ESLint和Stylelint也要同样加上exclude: /node_modules/并且ESLint建议用cache: true开启自己的缓存。注意ESLint缓存默认只缓存文件路径和mtime如果文件内容变了但mtime没变比如从Git恢复文件可能拿到脏缓存这一点在CI上偶尔会坑人。2.2 Resolve端把Webpack找文件的时间降下来Resolve慢的根源是Webpack的模块解析机制。当代码里写import something from ./utils而没有写全路径时Webpack需要依次尝试查找./utils是否有精确匹配尝试./utils.js、./utils.json、./utils.jsx等扩展名如果都找不到尝试./utils/index.js等目录入口每一个尝试都是一次文件系统IO。模块越多IO越多累计起来耗时就上去了。减少这部分的配置策略如下resolve: { extensions: [.js, .jsx, .json], mainFields: [module, main], modules: [path.resolve(__dirname, node_modules)], alias: { : path.resolve(__dirname, src), } }extensions只保留项目中真实用到的扩展名而且把高频扩展名放前面减少遍历次数alias给src目录起别名后代码里的深层相对路径可以直接写/components/Button既省了Webpack的逐级向上查找也让代码更整洁modules指定只从项目自己的node_modules里查找可以避免Webpack一直往上层的node_modules翻这些配置单独看每一项都只是微小的节省但叠加起来resolve阶段从10秒降到6秒并不稀奇。2.3 Plugin端警惕那些方便但昂贵的插件有一类插件在开发模式下是纯粹的开销比如webpack-bundle-analyzer。它做产物分析很有用但如果被无脑加进了日常dev构建每次启动都要额外花几秒去生成stats文件属于典型的看着方便实则拖慢。我的做法是只通过环境变量控制分析插件的启用默认关闭只有在需要排查包体积时手动打开。const isAnalyze process.env.ANALYZE true; if (isAnalyze) { config.plugins.push(new BundleAnalyzerPlugin()); }另外HtmlWebpackPlugin在每次编译时都要重新生成HTML文件。如果项目页面不多比如只有一两个入口这个开销可以忽略但如果是多页应用有几十个模板页就应该关注这个插件的耗时。SMP的插件耗时榜能帮你判断它是不是需要优化。3. 缓存体系搭建从loader缓存到持久化缓存的一整套配置优化构建速度里缓存是见效最快但坑最多的领域。我见过一个项目同时开了四五种缓存机制构建速度没快多少反而经常遇到改了代码不生效的灵异事件。做缓存方案一定要理解每一层的原理和边界。3.1 Webpack内置持久化缓存Webpack 5Webpack 5最大的改进之一就是内置了持久化缓存机制可以用cache配置开启module.exports { cache: { type: filesystem, buildDependencies: { config: [__filename], }, }, };关键参数说明参数作用实践建议type: filesystem把编译缓存写入磁盘跨进程复用生产构建和开发构建都建议开启buildDependencies.config指定配置文件本身作为缓存依赖配置修改后自动失效通常加入webpack.config.js和babel.config.jscacheDirectory缓存目录位置默认在node_modules/.cacheCI上注意清理策略用了内置缓存之后很多第三方缓存库比如hard-source-webpack-plugin就不需要了。这里明确说一下Webpack 5项目里不要再用HardSourceWebpackPlugin它和Webpack 5的持久化缓存机制冲突可能出现缓存互相覆盖、构建产物异常的问题。我遇到过两次线上代码被清空的事件排查到最后都是缓存冲突。3.2 Babel的cacheDirectory与cacheCompression取舍babel-loader的cacheDirectory: true是它的独立缓存和Webpack的持久化缓存是两个层级。前者缓存的是Babel转译的中间结果后者缓存的是模块图和处理后的模块内容。实践中我建议两层都开但有个细节要注意cacheDirectory默认缓存目录在node_modules/.cache/babel-loaderWebpack的filesystem缓存默认也在node_modules/.cache/webpack。如果CI环境每次都是全新安装依赖这两层缓存就都失效了需要CI配置里做持久化目录挂载才能享受到缓存加速。这里给出一份CI的.gitignore和清理策略参考# .gitignore node_modules/.cache/缓存目录不入Git但CI机器上可以设置一个固定的workspace让node_modules和缓存目录跨构建复用。注意清理策略比如固定每周清空一次缓存避免缓存文件无限膨胀导致磁盘占满。3.3 千万不要盲目全量缓存有一个场景我很警惕项目用了自定义的babel插件或webpack插件插件本身有状态或依赖外部文件。这种情况下持久化缓存可能过度智能——Webpack可能因为判断缓存未失效而跳过重新编译但你其实是改了某个非标准依赖文件导致构建结果没更新。遇到这类问题我建议给buildDependencies把项目里可能影响编译的配置文件都列全实在排查不出原因时直接删除node_modules/.cache再构建一次确认是不是缓存问题删除缓存目录后如果一切正常就说明是缓存的依赖追踪不完整需要回到配置层面补全依赖声明。4. 多进程并行与增量构建的实战经验单线程是Webpack的基本工作方式。在CPU多核资源充足的情况下把一部分工作拆给子进程并行做是进一步压榨性能的手段。但并行不是免费的进程通信有开销盲目并行反而会让小项目变慢。4.1 thread-loader的正确使用姿势thread-loader的原理是把后续loader的工作放到worker pool里执行。官方和社区推荐的一般用法是配合babel-loader和ts-loader{ test: /\.js$/, use: [ thread-loader, babel-loader ] }默认配置下thread-loader会启动os.cpus().length - 1个worker。对大型项目来说这个配置能让babel编译耗时砍半但对小型项目启动worker池本身就要200到400毫秒如果每轮构建的编译量本来只需要一两秒这个开销占比反而很高。我的判断标准是冷启动阶段babel编译耗时超过8秒时才值得引入thread-loader。另外注意thread-loader不能和某些有状态的loader一起用比如cache-loader它们曾经用于链式缓存但现在Webpack 5的持久化缓存完全能替代它。4.2 terser-webpack-plugin的并行压缩生产构建里JS压缩是个大头。terser-webpack-plugin默认已经开启了并行在Webpack 5里还会自动根据CPU核心数决定worker数量。如果你想手动控制可以这样写const TerserPlugin require(terser-webpack-plugin); module.exports { optimization: { minimize: true, minimizer: [ new TerserPlugin({ parallel: 4, terserOptions: { compress: { drop_console: true, }, }, }), ], }, };parallel: 4表示用4个进程做压缩。这里有个经验并行数不是越多越好。当并行数超过CPU物理核心数时进程间切换CPU的代价会超过并行收益。一般设置为核心数减一比较稳。4.3 fork-ts-checker-webpack-plugin把类型检查和编译解耦如果项目使用TypeScript直接用ts-loader做类型检查会严重拖慢构建因为ts-loader的默认行为是在编译文件时同步做类型检查。社区标准方案是{ test: /\.tsx?$/, use: [ { loader: ts-loader, options: { transpileOnly: true, }, }, ], }, plugins: [ new ForkTsCheckerWebpackPlugin(), ]transpileOnly: true让ts-loader只做转译、不做类型检查类型检查交给独立的ForkTsCheckerWebpackPlugin进程在后台完成。这样既保留了类型安全的保障又不会阻塞构建。但要注意transpileOnly模式下的转译使用的是isolatedModules语义不支持const enum和namespace这类需要跨文件上下文的功能。如果你的TS代码大量使用了const enum先跑一遍全量类型检查找出来把const enum改成普通枚举否则切到transpileOnly后会报运行时错误而且往往在浏览器里才暴露。5. 产物层面的优化Code Splitting、Tree Shaking与CDN迁移的取舍构建优化不光是构建变快还有一层是构建出来的东西更好用。产物优化对构建速度的影响是间接的——分包合理后增量构建时Webpack只需要处理变更的chunk而不是整个应用。5.1 Code Splitting的三种拆法Webpack的代码分割有三个层级入口拆包entry split多页面应用里每个页面一个入口天然地分成多个chunk共享依赖拆分splitChunks把多入口共享的react、vue等第三方库提取成独立的vendor chunk动态导入dynamic import路由级别的懒加载把每个路由页面拆成独立chunksplitChunks是配置最灵活、也最容易出问题的地方。我见过不少项目把splitChunks写成这样splitChunks: { chunks: all, minSize: 20000, maxSize: 0, minChunks: 1, maxAsyncRequests: 30, maxInitialRequests: 30, }参数全开的结果是每个小模块都可能被拆出去async请求数甚至能到30个首屏页面发起一大堆并行请求HTTP/1.1下浏览器对同一域名有连接数限制反而拖慢了加载。我建议的实践是设置合理的上下限splitChunks: { chunks: all, cacheGroups: { reactVendor: { test: /[\\/]node_modules[\\/](react|react-dom)[\\/]/, name: vendor-react, priority: 10, }, antd: { test: /[\\/]node_modules[\\/]antd[\\/]/, name: vendor-antd, priority: 5, }, }, }按业务实际把最大的几个第三方依赖单独分组命名比散装拆分更可控。priority用来控制分组优先级先被匹配的组优先。5.2 Tree Shaking不是Webpack免费送的Tree Shaking依赖一个前提模块必须用ESM的import/export语法不能有副作用。很多人以为只要用了mode: production就有Tree Shaking实际上Webpack只会剔除明确未使用的导出而且只是安全地剔除它判断为无副作用的代码。实际操作中我建议这样做保证源代码和第三方库都提供ESM版本。mainFields: [module, main]的配置能让Webpack优先使用ESM入口在package.json里声明sideEffects: false告诉Webpack整个包的模块都没有副作用可以安全shake如果项目有CSS文件sideEffects要写成[*.css]否则CSS被Webpack当成无副作用模块给摇掉这里有个从实践中来的坑某次我优化一个组件库项目配置了sideEffects: false后全局引入的import ./polyfill被优化没了页面在IE上直接白屏。排查半天发现polyfill里有一行window.Promise ...这种对全局对象的赋值属于副作用Webpack按声明把它当成可摇掉的内容了。解决办法是在sideEffects数组里把polyfill文件路径加进去。5.3 CDN迁移和externals的正确操作如果公司有CDN资源把体积巨大且不常变的库比如react、lodash通过externals指到CDN能明显减少打包体积externals: { react: React, react-dom: ReactDOM, }注意用externals意味着HTML里必须手动引入对应的CDN script标签。这意味着开发环境的本地调试和生产环境必须保持一致否则开发时用的是npm包生产用的是CDN可能出现版本不一致导致的问题外网环境访问CDN失败时整个应用可能挂掉国内部分网络环境下访问国外CDN服比如unpkg速度可能很慢我的建议是只有规模足够大、收益明显的项目才配考虑externals。中小项目打包产物里那几MB的第三方库用户带宽和缓存通常都能扛住引入CDN反而让架构多了几层不确定性。6. 老Webpack项目改造中的几个憋屈场景与妥协方案真正负责过实际项目的都知道Webpack优化不是照文档改一行配置就完事的爽文故事。项目越老遗留下来的约束就越多很多理论上正确的操作根本做不了需要在工程现实和最佳实践之间做妥协。我挑几个典型场景说说。6.1 Webpack 3/4老项目的有限优化手段如果你还在维护Webpack 3或4的项目这类项目在企业里真不少很多Webpack 5的新特性用不了这时候能做什么Webpack 4可以这样做打开mode: production时Webpack 4会内置optimization.minimize和splitChunks把原本要手动配置UglifyJsPlugin和CommonsChunkPlugin的工作省掉使用hashedModuleIds替代原来的数字moduleIds避免每个模块ID因为顺序变化导致vendor缓存全部失效引入cache-loader做loader层的缓存使用thread-loader做并行Webpack 3的时代还需要手动配CommonsChunkPlugin做公共代码抽取它和后来的splitChunks在工作原理上有明显差异。如果你还在用Webpack 3我的第一建议是优先规划升级到Webpack 5在已经停止活跃维护的老版本上做深度优化技术债会越滚越大。6.2 大型monorepo场景下的构建优化现在不少团队在推行monorepo。Webpack在monorepo里最突出的问题是symlink解析node_modules下通过软链接引用工作区的包Webpack默认会解析到包的源码目录而不是构建产物目录如果有依赖循环解析链路会变得非常长。实践经验是在webpack配置里通过resolve.symlinks来控制是否跟随软链接。resolve.symlinks: false表示直接使用软链接指向的真实路径避免重复解析配合watchOptions.ignored把不相关的目录排除掉避免dev server和watch模式监听过多文件watchOptions: { ignored: /node_modules|dist|build/, aggregateTimeout: 300, poll: false, }aggregateTimeout的含义是文件变动后延迟多少毫秒再触发编译。改成300可以在保存高频操作时合并多次变更避免反复触发编译。但如果你的文件IO在虚拟文件系统比如Docker挂载卷、Windows WSL上事件响应可能不稳定这时poll: true才是保险做法。6.3 兼容性约束browserslist和polyfill的平衡老项目最大的痛是兼容性。很多浏览器需要polyfill才能跑现代语法。polyfill有两种引入方式babel/preset-env配合useBuiltIns: usage自动按需引入或者手动在入口文件引入完整的polyfill包。前者产物体积小但可能会漏掉某些动态场景的polyfill后者省心但体积大。我的建议是{ presets: [ [babel/preset-env, { useBuiltIns: usage, corejs: 3, targets: 0.25%, not dead }] ] }同时保留一个手动引入完整polyfill的入口比如safari 12的特判可以在定位到线上某些老机型异常时快速切换。7. 从Webpack切换到Vite之前先想清楚这几个问题说句实话现在社区里讨论Webpack优化绕不开为什么不直接用Vite这个选项。Vite基于esbuild和Rollup冷启动确实比Webpack快一个量级。但我的态度是务实的迁移不是免费的收益要具体问题具体分析。7.1 Vite快在哪慢在哪Vite快在开发模式它利用浏览器原生ESM只对当前访问的模块按需编译省去了Webpack启动时构建整个模块图的时间。但对于生产构建Vite使用Rollup做打包复杂项目的Rollup构建速度并不一定比Webpack快多少。另外Vite生态里部分核心插件比如某些老牌Rollup插件或Vue 2的适配方案成熟度不如Webpack遇到兼容问题时要自己踩坑。7.2 什么项目值得迁移什么项目别动我的判断框架是这样的适合迁移项目以标准ESM编写没用什么Webpack自定义插件团队技术栈和Vite生态吻合比如Vue 3或React 17开发体验是主要痛点生产构建时间可接受不建议迁移深度依赖了Webpack的loader链比如各种自定义loader处理图片、字体、CSS方案项目里存在大量CommonJS模块ESM转换时容易出现兼容问题老浏览器兼容要求苛刻Vite的默认打包target和polyfill策略需要大量调整团队没有多余精力处理工具链切换带来的问题很多时候这是核心原因7.3 渐进式共存把Vite当Webpack的补充而不是替代还有一个折中方案在dev环境给开发者一个vite模式的选择生产打包仍用webpack。但要注意两套构建链路的loader插件行为如果存在差异同样的代码在dev和生产里表现不同排查问题时需要两倍的上下文成本。我见过有团队这么干最后本意是为了提速结果维护成本反而膨胀了。如果决定迁移我的经验是按模块边界渐进迁移而不是一天之内把整个webpack配置翻译成vite。先用一个独立的子应用做试点跑通依赖注入、环境变量、构建产物三个维度后再逐步铺开。整个过程里保留webpack原配置作为回退方案给团队一个缓冲期。最后分享一个小技巧做Webpack优化这段时间我养成了一个习惯每次改完配置都会把构建产出里的stats信息保存一份记录优化前后的耗时数据。遇到好像变快了又好像没变的模糊状态时数据比我拍胸脯说这样改肯定有效要可信得多。用webpack --json stats.json就能生成一份原始的stats文件配合webpack-bundle-analyzer stats.json可以对产物做深入分析。这是排查体积问题时最常用的一招。如果你要动手优化自己的项目我建议按这样的顺序推进先跑SMP建立基线确认瓶颈再做include/exclude和resolve这类零风险配置然后开Webpack 5持久化缓存最后才考虑thread-loader和splitChunks。每一步都单独验证效果别把所有改动混在一次提交里。否则出了问题你根本不知道是哪一步引入的回归。
Webpack构建性能优化实战：从瓶颈定位到缓存与多进程并行配置
1. 先搞清楚项目到底慢在哪构建耗时画像与瓶颈定位接手过几个老项目的构建优化我发现一个特别有意思的现象大部分人说Webpack打包太慢的时候其实根本说不清慢在哪个环节。有人一上来就装thread-loader结果构建时间没降多少反而因为进程通信开销把简单的项目搞得更慢有人盲目开cache-loader缓存命中率低得可怜磁盘空间倒是占了不少。我自己的习惯是动任何优化手段之前先花十分钟做一次完整的构建耗时画像。这一步不做后面的所有优化都是猜。1.1 用speed-measure-webpack-plugin生成初始基线speed-measure-webpack-pluginSMP是分析Webpack各阶段耗时最直接的工具接入方式很简单const SpeedMeasurePlugin require(speed-measure-webpack-plugin); const smp new SpeedMeasurePlugin(); module.exports smp.wrap({ // 你的原有webpack配置 module: { rules: [] }, plugins: [] });跑一次构建控制台会输出每个loader和plugin的耗时排行。我拿一个实际项目举例这是典型的输出结构处理环节耗时占比babel-loader编译JS42.3s38%css-loader style-loader12.8s11%eslint-loader检查9.5s8%terser压缩21.6s19%module resolve10.2s9%在这个例子里babel-loader和terser两项加一起占了将近六成时间这才是优化的主战场。至于resolve阶段那10秒可能改一个配置就省下来了优先级反而不高。1.2 别只看总耗时要区分dev和build两个场景很多人犯的第二个错误是混着谈构建优化。开发模式的痛点是冷启动慢和热更新慢生产构建的痛点是压缩慢和分包不合理。两者优化的手段虽然有重叠但优先级完全不同。开发模式下我关心的核心指标是首次编译时间冷启动——决定你打开项目后要等多久才能开始干活文件修改后的增量编译时间——决定你改一行代码后多久能看到效果热更新HMR是否稳定——决定你需不需要手动刷新页面生产模式下我关心的是总构建时间——决定发版的等待成本产物体积和分包情况——决定用户首次访问的加载体验代码压缩的耗时占比——决定构建流水线是不是卡在这一个点上所以我建议先建立一张清单明确你要优化的是哪个场景再针对性地下手。结合我自己的经验大部分团队真正痛的是开发模式的冷启动和增量编译生产模式的耗时反而因为CI机器配置更高、可以接受。把有限的优化精力花在最痛的地方收益才最大。2. Loader、Resolve、Plugin三个高频瓶颈的削减方案定位到瓶颈之后接下来就是具体怎么削。我按Loader、Resolve、Plugin三块来拆每一块都有一些改完立刻见效的配置也有一些需要谨慎对待的坑。2.1 Loader端include/exclude是性价比最高的优化babel-loader之所以慢是因为它默认会对所有通过resolve规则进来的JS文件都做转译包括node_modules里的第三方代码。但实际上node_modules里的包绝大多数都已经发布成了ES5或者提供了构建好的产物根本不需要再过一遍Babel。{ test: /\.(js|mjs|jsx)$/, exclude: /node_modules/, use: { loader: babel-loader, options: { cacheDirectory: true, cacheCompression: false, } } }exclude: /node_modules/是我见过收益最高、风险最低的一项配置。很多项目没写这个等于白白让Babel多编译了几千个模块。加上之后冷启动时间普遍能降20%到30%。这里有个容易被忽略的小细节cacheCompression在开发模式下建议设为false。它的作用是决定缓存的产物是否压缩。压缩能省磁盘空间但写入和读取都要额外消耗CPU。开发模式的机器一般不缺那点磁盘关掉压缩能让第二次构建的加载速度快不少。如果项目里用了ESLint和Stylelint也要同样加上exclude: /node_modules/并且ESLint建议用cache: true开启自己的缓存。注意ESLint缓存默认只缓存文件路径和mtime如果文件内容变了但mtime没变比如从Git恢复文件可能拿到脏缓存这一点在CI上偶尔会坑人。2.2 Resolve端把Webpack找文件的时间降下来Resolve慢的根源是Webpack的模块解析机制。当代码里写import something from ./utils而没有写全路径时Webpack需要依次尝试查找./utils是否有精确匹配尝试./utils.js、./utils.json、./utils.jsx等扩展名如果都找不到尝试./utils/index.js等目录入口每一个尝试都是一次文件系统IO。模块越多IO越多累计起来耗时就上去了。减少这部分的配置策略如下resolve: { extensions: [.js, .jsx, .json], mainFields: [module, main], modules: [path.resolve(__dirname, node_modules)], alias: { : path.resolve(__dirname, src), } }extensions只保留项目中真实用到的扩展名而且把高频扩展名放前面减少遍历次数alias给src目录起别名后代码里的深层相对路径可以直接写/components/Button既省了Webpack的逐级向上查找也让代码更整洁modules指定只从项目自己的node_modules里查找可以避免Webpack一直往上层的node_modules翻这些配置单独看每一项都只是微小的节省但叠加起来resolve阶段从10秒降到6秒并不稀奇。2.3 Plugin端警惕那些方便但昂贵的插件有一类插件在开发模式下是纯粹的开销比如webpack-bundle-analyzer。它做产物分析很有用但如果被无脑加进了日常dev构建每次启动都要额外花几秒去生成stats文件属于典型的看着方便实则拖慢。我的做法是只通过环境变量控制分析插件的启用默认关闭只有在需要排查包体积时手动打开。const isAnalyze process.env.ANALYZE true; if (isAnalyze) { config.plugins.push(new BundleAnalyzerPlugin()); }另外HtmlWebpackPlugin在每次编译时都要重新生成HTML文件。如果项目页面不多比如只有一两个入口这个开销可以忽略但如果是多页应用有几十个模板页就应该关注这个插件的耗时。SMP的插件耗时榜能帮你判断它是不是需要优化。3. 缓存体系搭建从loader缓存到持久化缓存的一整套配置优化构建速度里缓存是见效最快但坑最多的领域。我见过一个项目同时开了四五种缓存机制构建速度没快多少反而经常遇到改了代码不生效的灵异事件。做缓存方案一定要理解每一层的原理和边界。3.1 Webpack内置持久化缓存Webpack 5Webpack 5最大的改进之一就是内置了持久化缓存机制可以用cache配置开启module.exports { cache: { type: filesystem, buildDependencies: { config: [__filename], }, }, };关键参数说明参数作用实践建议type: filesystem把编译缓存写入磁盘跨进程复用生产构建和开发构建都建议开启buildDependencies.config指定配置文件本身作为缓存依赖配置修改后自动失效通常加入webpack.config.js和babel.config.jscacheDirectory缓存目录位置默认在node_modules/.cacheCI上注意清理策略用了内置缓存之后很多第三方缓存库比如hard-source-webpack-plugin就不需要了。这里明确说一下Webpack 5项目里不要再用HardSourceWebpackPlugin它和Webpack 5的持久化缓存机制冲突可能出现缓存互相覆盖、构建产物异常的问题。我遇到过两次线上代码被清空的事件排查到最后都是缓存冲突。3.2 Babel的cacheDirectory与cacheCompression取舍babel-loader的cacheDirectory: true是它的独立缓存和Webpack的持久化缓存是两个层级。前者缓存的是Babel转译的中间结果后者缓存的是模块图和处理后的模块内容。实践中我建议两层都开但有个细节要注意cacheDirectory默认缓存目录在node_modules/.cache/babel-loaderWebpack的filesystem缓存默认也在node_modules/.cache/webpack。如果CI环境每次都是全新安装依赖这两层缓存就都失效了需要CI配置里做持久化目录挂载才能享受到缓存加速。这里给出一份CI的.gitignore和清理策略参考# .gitignore node_modules/.cache/缓存目录不入Git但CI机器上可以设置一个固定的workspace让node_modules和缓存目录跨构建复用。注意清理策略比如固定每周清空一次缓存避免缓存文件无限膨胀导致磁盘占满。3.3 千万不要盲目全量缓存有一个场景我很警惕项目用了自定义的babel插件或webpack插件插件本身有状态或依赖外部文件。这种情况下持久化缓存可能过度智能——Webpack可能因为判断缓存未失效而跳过重新编译但你其实是改了某个非标准依赖文件导致构建结果没更新。遇到这类问题我建议给buildDependencies把项目里可能影响编译的配置文件都列全实在排查不出原因时直接删除node_modules/.cache再构建一次确认是不是缓存问题删除缓存目录后如果一切正常就说明是缓存的依赖追踪不完整需要回到配置层面补全依赖声明。4. 多进程并行与增量构建的实战经验单线程是Webpack的基本工作方式。在CPU多核资源充足的情况下把一部分工作拆给子进程并行做是进一步压榨性能的手段。但并行不是免费的进程通信有开销盲目并行反而会让小项目变慢。4.1 thread-loader的正确使用姿势thread-loader的原理是把后续loader的工作放到worker pool里执行。官方和社区推荐的一般用法是配合babel-loader和ts-loader{ test: /\.js$/, use: [ thread-loader, babel-loader ] }默认配置下thread-loader会启动os.cpus().length - 1个worker。对大型项目来说这个配置能让babel编译耗时砍半但对小型项目启动worker池本身就要200到400毫秒如果每轮构建的编译量本来只需要一两秒这个开销占比反而很高。我的判断标准是冷启动阶段babel编译耗时超过8秒时才值得引入thread-loader。另外注意thread-loader不能和某些有状态的loader一起用比如cache-loader它们曾经用于链式缓存但现在Webpack 5的持久化缓存完全能替代它。4.2 terser-webpack-plugin的并行压缩生产构建里JS压缩是个大头。terser-webpack-plugin默认已经开启了并行在Webpack 5里还会自动根据CPU核心数决定worker数量。如果你想手动控制可以这样写const TerserPlugin require(terser-webpack-plugin); module.exports { optimization: { minimize: true, minimizer: [ new TerserPlugin({ parallel: 4, terserOptions: { compress: { drop_console: true, }, }, }), ], }, };parallel: 4表示用4个进程做压缩。这里有个经验并行数不是越多越好。当并行数超过CPU物理核心数时进程间切换CPU的代价会超过并行收益。一般设置为核心数减一比较稳。4.3 fork-ts-checker-webpack-plugin把类型检查和编译解耦如果项目使用TypeScript直接用ts-loader做类型检查会严重拖慢构建因为ts-loader的默认行为是在编译文件时同步做类型检查。社区标准方案是{ test: /\.tsx?$/, use: [ { loader: ts-loader, options: { transpileOnly: true, }, }, ], }, plugins: [ new ForkTsCheckerWebpackPlugin(), ]transpileOnly: true让ts-loader只做转译、不做类型检查类型检查交给独立的ForkTsCheckerWebpackPlugin进程在后台完成。这样既保留了类型安全的保障又不会阻塞构建。但要注意transpileOnly模式下的转译使用的是isolatedModules语义不支持const enum和namespace这类需要跨文件上下文的功能。如果你的TS代码大量使用了const enum先跑一遍全量类型检查找出来把const enum改成普通枚举否则切到transpileOnly后会报运行时错误而且往往在浏览器里才暴露。5. 产物层面的优化Code Splitting、Tree Shaking与CDN迁移的取舍构建优化不光是构建变快还有一层是构建出来的东西更好用。产物优化对构建速度的影响是间接的——分包合理后增量构建时Webpack只需要处理变更的chunk而不是整个应用。5.1 Code Splitting的三种拆法Webpack的代码分割有三个层级入口拆包entry split多页面应用里每个页面一个入口天然地分成多个chunk共享依赖拆分splitChunks把多入口共享的react、vue等第三方库提取成独立的vendor chunk动态导入dynamic import路由级别的懒加载把每个路由页面拆成独立chunksplitChunks是配置最灵活、也最容易出问题的地方。我见过不少项目把splitChunks写成这样splitChunks: { chunks: all, minSize: 20000, maxSize: 0, minChunks: 1, maxAsyncRequests: 30, maxInitialRequests: 30, }参数全开的结果是每个小模块都可能被拆出去async请求数甚至能到30个首屏页面发起一大堆并行请求HTTP/1.1下浏览器对同一域名有连接数限制反而拖慢了加载。我建议的实践是设置合理的上下限splitChunks: { chunks: all, cacheGroups: { reactVendor: { test: /[\\/]node_modules[\\/](react|react-dom)[\\/]/, name: vendor-react, priority: 10, }, antd: { test: /[\\/]node_modules[\\/]antd[\\/]/, name: vendor-antd, priority: 5, }, }, }按业务实际把最大的几个第三方依赖单独分组命名比散装拆分更可控。priority用来控制分组优先级先被匹配的组优先。5.2 Tree Shaking不是Webpack免费送的Tree Shaking依赖一个前提模块必须用ESM的import/export语法不能有副作用。很多人以为只要用了mode: production就有Tree Shaking实际上Webpack只会剔除明确未使用的导出而且只是安全地剔除它判断为无副作用的代码。实际操作中我建议这样做保证源代码和第三方库都提供ESM版本。mainFields: [module, main]的配置能让Webpack优先使用ESM入口在package.json里声明sideEffects: false告诉Webpack整个包的模块都没有副作用可以安全shake如果项目有CSS文件sideEffects要写成[*.css]否则CSS被Webpack当成无副作用模块给摇掉这里有个从实践中来的坑某次我优化一个组件库项目配置了sideEffects: false后全局引入的import ./polyfill被优化没了页面在IE上直接白屏。排查半天发现polyfill里有一行window.Promise ...这种对全局对象的赋值属于副作用Webpack按声明把它当成可摇掉的内容了。解决办法是在sideEffects数组里把polyfill文件路径加进去。5.3 CDN迁移和externals的正确操作如果公司有CDN资源把体积巨大且不常变的库比如react、lodash通过externals指到CDN能明显减少打包体积externals: { react: React, react-dom: ReactDOM, }注意用externals意味着HTML里必须手动引入对应的CDN script标签。这意味着开发环境的本地调试和生产环境必须保持一致否则开发时用的是npm包生产用的是CDN可能出现版本不一致导致的问题外网环境访问CDN失败时整个应用可能挂掉国内部分网络环境下访问国外CDN服比如unpkg速度可能很慢我的建议是只有规模足够大、收益明显的项目才配考虑externals。中小项目打包产物里那几MB的第三方库用户带宽和缓存通常都能扛住引入CDN反而让架构多了几层不确定性。6. 老Webpack项目改造中的几个憋屈场景与妥协方案真正负责过实际项目的都知道Webpack优化不是照文档改一行配置就完事的爽文故事。项目越老遗留下来的约束就越多很多理论上正确的操作根本做不了需要在工程现实和最佳实践之间做妥协。我挑几个典型场景说说。6.1 Webpack 3/4老项目的有限优化手段如果你还在维护Webpack 3或4的项目这类项目在企业里真不少很多Webpack 5的新特性用不了这时候能做什么Webpack 4可以这样做打开mode: production时Webpack 4会内置optimization.minimize和splitChunks把原本要手动配置UglifyJsPlugin和CommonsChunkPlugin的工作省掉使用hashedModuleIds替代原来的数字moduleIds避免每个模块ID因为顺序变化导致vendor缓存全部失效引入cache-loader做loader层的缓存使用thread-loader做并行Webpack 3的时代还需要手动配CommonsChunkPlugin做公共代码抽取它和后来的splitChunks在工作原理上有明显差异。如果你还在用Webpack 3我的第一建议是优先规划升级到Webpack 5在已经停止活跃维护的老版本上做深度优化技术债会越滚越大。6.2 大型monorepo场景下的构建优化现在不少团队在推行monorepo。Webpack在monorepo里最突出的问题是symlink解析node_modules下通过软链接引用工作区的包Webpack默认会解析到包的源码目录而不是构建产物目录如果有依赖循环解析链路会变得非常长。实践经验是在webpack配置里通过resolve.symlinks来控制是否跟随软链接。resolve.symlinks: false表示直接使用软链接指向的真实路径避免重复解析配合watchOptions.ignored把不相关的目录排除掉避免dev server和watch模式监听过多文件watchOptions: { ignored: /node_modules|dist|build/, aggregateTimeout: 300, poll: false, }aggregateTimeout的含义是文件变动后延迟多少毫秒再触发编译。改成300可以在保存高频操作时合并多次变更避免反复触发编译。但如果你的文件IO在虚拟文件系统比如Docker挂载卷、Windows WSL上事件响应可能不稳定这时poll: true才是保险做法。6.3 兼容性约束browserslist和polyfill的平衡老项目最大的痛是兼容性。很多浏览器需要polyfill才能跑现代语法。polyfill有两种引入方式babel/preset-env配合useBuiltIns: usage自动按需引入或者手动在入口文件引入完整的polyfill包。前者产物体积小但可能会漏掉某些动态场景的polyfill后者省心但体积大。我的建议是{ presets: [ [babel/preset-env, { useBuiltIns: usage, corejs: 3, targets: 0.25%, not dead }] ] }同时保留一个手动引入完整polyfill的入口比如safari 12的特判可以在定位到线上某些老机型异常时快速切换。7. 从Webpack切换到Vite之前先想清楚这几个问题说句实话现在社区里讨论Webpack优化绕不开为什么不直接用Vite这个选项。Vite基于esbuild和Rollup冷启动确实比Webpack快一个量级。但我的态度是务实的迁移不是免费的收益要具体问题具体分析。7.1 Vite快在哪慢在哪Vite快在开发模式它利用浏览器原生ESM只对当前访问的模块按需编译省去了Webpack启动时构建整个模块图的时间。但对于生产构建Vite使用Rollup做打包复杂项目的Rollup构建速度并不一定比Webpack快多少。另外Vite生态里部分核心插件比如某些老牌Rollup插件或Vue 2的适配方案成熟度不如Webpack遇到兼容问题时要自己踩坑。7.2 什么项目值得迁移什么项目别动我的判断框架是这样的适合迁移项目以标准ESM编写没用什么Webpack自定义插件团队技术栈和Vite生态吻合比如Vue 3或React 17开发体验是主要痛点生产构建时间可接受不建议迁移深度依赖了Webpack的loader链比如各种自定义loader处理图片、字体、CSS方案项目里存在大量CommonJS模块ESM转换时容易出现兼容问题老浏览器兼容要求苛刻Vite的默认打包target和polyfill策略需要大量调整团队没有多余精力处理工具链切换带来的问题很多时候这是核心原因7.3 渐进式共存把Vite当Webpack的补充而不是替代还有一个折中方案在dev环境给开发者一个vite模式的选择生产打包仍用webpack。但要注意两套构建链路的loader插件行为如果存在差异同样的代码在dev和生产里表现不同排查问题时需要两倍的上下文成本。我见过有团队这么干最后本意是为了提速结果维护成本反而膨胀了。如果决定迁移我的经验是按模块边界渐进迁移而不是一天之内把整个webpack配置翻译成vite。先用一个独立的子应用做试点跑通依赖注入、环境变量、构建产物三个维度后再逐步铺开。整个过程里保留webpack原配置作为回退方案给团队一个缓冲期。最后分享一个小技巧做Webpack优化这段时间我养成了一个习惯每次改完配置都会把构建产出里的stats信息保存一份记录优化前后的耗时数据。遇到好像变快了又好像没变的模糊状态时数据比我拍胸脯说这样改肯定有效要可信得多。用webpack --json stats.json就能生成一份原始的stats文件配合webpack-bundle-analyzer stats.json可以对产物做深入分析。这是排查体积问题时最常用的一招。如果你要动手优化自己的项目我建议按这样的顺序推进先跑SMP建立基线确认瓶颈再做include/exclude和resolve这类零风险配置然后开Webpack 5持久化缓存最后才考虑thread-loader和splitChunks。每一步都单独验证效果别把所有改动混在一次提交里。否则出了问题你根本不知道是哪一步引入的回归。
用法、场景与避坑)
