UmiJS 4 打包优化实战umi.js 过大、首屏加载慢先用代码分割做对这几步【免费下载链接】umiA framework in react community ✨项目地址: https://gitcode.com/GitHub_Trending/um/umiUmiJS 4 项目构建后dist 里那个几 MB 的 umi.js 常常是首屏加载慢的直接元凶。别急着堆配置下面这条先诊断、再拆包、后验证的路径可以帮你把主包体积压下来同时保住长期缓存的命中率。1. 先判断你的项目是不是真的主包过大加载慢不等于主包大。在动手之前先做三个检查确认问题确实出在构建产物上打开构建产物看一眼。执行生产构建后浏览dist目录看 umi.js 是否明显大于其他 chunk、静态资源总和。如果它占大头优化方向成立如果大头是图片字体等静态资源那要优先处理资源本身。打开网络面板看请求耗时。刷新页面观察 umi.js 的下载时间和解析执行耗时。下载慢说明体积或带宽问题解析慢说明文件内代码量过大两者的解法都指向拆分。留意缓存行为。如果用户每次小版本发布后都要重新下载整个 umi.js说明业务代码和依赖被捆在了一起缓存基本失效。只有确认主 JS 文件过大 缓存利用差这两点后下面的拆分策略才有意义。2. 弄清 umi.js 为什么会变大常见的成因有四类你可以对照着自己的项目逐一排查第三方依赖和业务代码捆在同一文件里。UmiJS 4 默认按路由拆包、按需加载但 node_modules 中的库如果没有被单独拆出就会跟着主文件一起下发。公共模块重复或集中。多个路由页面共用的组件、工具函数被打包进主 chunk路由越多文件越大。大型组件被静态引入。比如整页引入图表库、富文本编辑器、代码高亮库只要被同步 import体积就全部算进首屏。构建后没有做过体积分析。缺少数据支撑时优化容易变成凭感觉改配置。建议先用官方文档里的产物分析手段拿到数据设置ANALYZE1环境变量再执行构建即可得到一份可视化的包体构成报告告诉你每个 chunk 由哪些模块组成、谁占了大头。操作细节可参考 docs/docs/docs/guides/env-variables.md。有了这张体检报告后续的拆分才有的放矢。3. 用内置分包策略拆出第三方依赖UmiJS 4 内置了codeSplitting配置项提供三种 JS 拆分策略bigVendors、depPerChunk、granularChunks含义和取舍在 docs/docs/docs/api/config.md 中有明确说明。简单概括bigVendors把所有异步依赖合并成一个大 vendors 文件简单但单文件大、缓存效率低depPerChunk按包名版本逐个拆文件缓存好但请求数多granularChunks折中方案——框架类库react、react-router 等单独成块超过一定体积的库按包拆分被两个以上路由引用的模块抽成共享块。官方文档 docs/docs/blog/code-splitting.md 的建议是无特殊场景优先使用granularChunks。对应配置只有几行// .umirc.ts 或 config/config.ts export default { codeSplitting: { jsStrategy: granularChunks, }, };为什么这样改这个策略只作用于生产构建它让变更频率低的框架代码和变更频率低的第三方库各自独立成文件业务代码留在自己的路由 chunk 里。改动业务页面时用户通常只需重新下载对应路由块而 framework、vendors 类文件可以继续命中浏览器缓存。可能带来的变化dist 中会出现多个以库名命名的文件请求数量有所增加在 HTTP/2 下几十个并行请求不是问题但如果你的部署环境仍停留在 HTTP/1.1 且用户网络较差可以先从影响面小的depPerChunk试起再对比产物后决定是否升级到granularChunks。策略的具体实现可以查看 packages/preset-umi/src/features/codeSplitting/ 目录下的源码确认它与你项目的 webpack 行为是否吻合。4. 把重组件改成懒加载但别滥用拆分策略解决的是依赖放哪里而懒加载解决的是什么时候加载。对于明显偏重的模块——图表、编辑器、报表、地图这类引用了大型第三方库的组件建议用动态导入推迟到真正使用时再加载import { lazy, Suspense } from react; // 只有用户进入该功能时才下载这块代码 const ChartPanel lazy(() import(./ChartPanel));使用时外层包一个Suspense并提供加载占位即可。为什么这样改UmiJS 4 默认已经按路由拆包但路由内部的大块头默认仍会随该路由一起下载。改成lazy后构建工具会把它们拆成独立的异步 chunk首屏和该路由的主块都变轻。使用边界这一点容易被忽略不要给首屏关键组件懒加载否则会多一次串行请求反而拖慢白屏时间不要为了拆包而拆包几 KB 的小组件动态导入带来的请求开销可能大于收益懒加载组件必须配Suspense否则首帧会闪断甚至报错懒加载的 chunk 依然受第 3 步codeSplitting策略影响两者叠加效果最好。5. 依赖与公共模块让共享代码只下载一次拆包策略配置完之后还要关注两类容易藏在主包里的代码框架级公共模块granularChunks已把 react、react-router 等固定为framework块被多个路由引用的业务模块会生成shared-*块确认产物中出现这些命名说明共享逻辑被正确抽离按需引用大库像 lodash 这类工具库如果只用了debounce、get两个函数建议改为精确路径导入而不是整包引入从源头减小进入任何 chunk 的体积。这类细节配合产物分析报告逐项核对比一次性全局改配置更安全。另外如果你使用了 MFSU 加速开发构建注意它主要影响本地开发体验生产构建的拆包行为仍以 webpack 配置为准不要把开发时的产物体积当作判断依据。6. 验证拆包是否真的生效改完配置不等于优化完成建议按下面三步验证每步都回答一个具体问题对比产物构成。构建前后各跑一次ANALYZE1构建对比 umi.js 是否变小、是否出现独立的 framework / 库名 chunk / shared 块。如果主文件只是换了个名字、体积没降说明大头不在依赖而在业务代码本身需要回到第 4 步做懒加载。数请求与总传输量。用网络面板确认首屏实际下载的 JS 总字节数下降且拆出的 chunk 没有被首屏串行等待。目标通常是主文件显著变小首屏总请求时间更短而不是 chunk 数量变多就完事。模拟二次访问看缓存。清缓存前刷新一次页面确认 framework、vendors 类文件走的是缓存from disk cache / memory cache只有业务 chunk 发生重新下载。这一步验证的是缓存命中率这一优化目的有没有真正达成。7. 上线前的检查清单配置合并到主干之前过一遍下面这张清单能避免大多数拆包翻车生产构建产物中 umi.js 体积下降且没有异常的单文件巨型 chunk路由切换时对应的异步 chunk 能正常加载loading.tsx的加载态体验可接受懒加载组件均有Suspense包裹错误边界能捕获加载失败二次刷新时 framework / vendors 类文件命中缓存服务端已开启 Gzip 或 Brotli 压缩同样的 JS 压缩后体积可能差数倍静态资源可走 CDN且文件名带内容 hash便于长期缓存。压缩和 CDN 属于部署侧能力它们不改变代码结构但能让拆分后的每个小块以更快的速度送达用户是拆包收益能兑现的最后一环。小结处理 umi.js 过大的合理顺序是先用产物分析确认问题再用codeSplitting策略拆出依赖对确重的组件补懒加载最后用对比产物 观察缓存验证效果。整套流程不涉及侵入式改造风险可控。如果你的项目主包问题依旧明显回到分析报告里逐个排查最大的模块比继续调参数更有效。【免费下载链接】umiA framework in react community ✨项目地址: https://gitcode.com/GitHub_Trending/um/umi创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考