UmiJS 4 打包体积优化:代码分割让 umi.js 减半【免费下载链接】umiA framework in react community ✨项目地址: https://gitcode.com/GitHub_Trending/um/umi场景:生产环境里 2.6 MB 的 umi.js做 UmiJS 4 打包优化,最常遇到的是这个画面:项目发到生产环境,打开 Network 面板,umi.js 赫然 2.6 MB,首屏白屏 3 秒才出内容。这就是典型的 umi.js 体积过大——业务代码和三方依赖全塞在一个主包里,浏览器必须下载、解析完它才能渲染任何页面,首屏加载慢的锅它背定了。解决思路就一个字:拆,也就是 代码分割(code splitting,把一个大文件拆成多个按需加载的小文件)。如何用 DevTools 确认体积问题 别凭感觉,先量化。本地构建后看一眼产物:npm run build ls -lh dist/*.js;或者部署后打开 DevTools 的 Network 面板,按 JS 过滤,看主包的 Transfer Size。判断标准很简单:主包大于 1 MB 就该动手,大于 2 MB 慢网用户基本会骂人。想看清大文件里到底装了什么,再加一条ANALYZEtrue npm run build,会输出一张产物构成图,体积大头一目了然。granularChunks 最简配置Umi 4 默认已按路由拆包(每个页面是独立 chunk),所以主包偏大通常不是页面代码,而是首屏引入的三方依赖被打包在一起。官方 codeSplitting 提供了 3 种策略,无特殊场景直接上 granularChunks 就行,它按依赖包粒度拆分,缓存效率最好:// .umirc.ts export default { codeSplitting: { jsStrategy: granularChunks, }, };改完npm run build,看 dist 下是否出现多个 chunk 文件。granularChunks 的分包逻辑是:react、react-dom、history 等框架层库合并成一个 framework.js;超过 160 KB 的大依赖单独拆成 xxx-lib.js;被多个页面复用的模块提取成 shared 块。效果是首次访问只拉一个较小的主包,用户每跳一个页面才加载对应 chunk;回访时 framework.js 等直接命中缓存,几乎不用重新下载。策略细节可查 代码拆分指南 与 codeSplitting 配置说明。还想再压一压:动态导入与依赖分包granularChunks 解决的是依赖怎么放。如果你还想再压一压,两个低成本补强。一是动态导入:引用了图表、富文本等重依赖的大组件,改成 React.lazy 动态导入(lazy loading:组件被用到时才加载),用 Suspense 在加载期间占位——const BigChart lazy(() import(./BigChart))再套一层Suspense即可,这个组件的代码就单独成一个 chunk。二是依赖分包:配置chunks: [vendors, umi],让构建把三方依赖和框架代码分别独立成包,和你频繁改动的业务代码分开缓存,业务改一行也不用重新下载整个依赖。优化后看哪几个指标 ✅量化参考:启用粒度化分块后,主包体积通常降 50%–70%,首屏加载时间缩短 30%–60%,缓存命中率明显提升。但别直接抄数字,以你项目的 Lighthouse 实测为准——改前后各跑一次,对比 TTI 和 LCP;再到 Network 面板看 JS 的 Transfer Size 总和,必要时切到慢速网络模拟,确认首屏没有变慢。分包拆得再细,如果首屏请求数暴涨反而拖慢加载,那就退回去调粒度。主路径就一条:改一行 codeSplitting,让代码分割把主包拆开。建议你先动这一处,跑一次 build 对比 dist 体积,再决定要不要上动态导入和手动拆 chunk——性能优化靠数据说话,别一次改完所有配置。【免费下载链接】umiA framework in react community ✨项目地址: https://gitcode.com/GitHub_Trending/um/umi创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考