Umi 打包优化指南把 2.6MB 的 umi.js 主包拆到首屏秒开【免费下载链接】umiA framework in react community ✨项目地址: https://gitcode.com/GitHub_Trending/um/umiUmi 4 项目上线后浏览器要下载完 2.6MB 的 umi.js 才渲染首屏弱网环境下交互时间逼近 5 秒跳出率跟着涨。主包越大每次发版全量用户都要重新下载一遍缓存形同虚设。这篇讲 4 个从一行配置到自定义拆包的 Umi 打包优化手段配合验证方法让主包体积降 50% 以上。主包为什么会长到 2.6MBUmi 默认只按路由拆包每个页面是一个 chunk但框架运行时、公共依赖、以及被多个页面静态 import 的第三方库会全部沉淀进 umi.js 主包。业务代码越多这个兜底块越大——它不是某一行代码的锅而是哪些代码被同步 import 了多少次的总结果。 先定位用 ANALYZE 看清主包构成动手改之前先量化。构建时带上ANALYZE1环境变量Umi 会启动可视化分析页按模块展示每个 chunk 的体积占比$ ANALYZE1 umi build重点看两处node_modules 占了主包多少、哪几个第三方库体积最大。这决定你后面选granularChunks还是自定义 cacheGroup。相关环境变量用法见 docs/docs/docs/guides/env-variables.md。启用 granularChunks 粒度化分块在.umirc.ts加一段codeSplitting配置开启 Umi 内置的自动分包策略// .umirc.ts export default { codeSplitting: { jsStrategy: granularChunks, }, };这个策略只做生产环境生效见 packages/preset-umi/src/features/codeSplitting/codeSplitting.ts 实现它把拆包分成三层react、react-dom、react-router 等框架包强制抽成frameworkchunk超过 160KB 的 node_modules 依赖按包名拆成独立xxx-lib文件被两个以上异步 chunk 共享的模块合成shared-xxx。效果是 2.6MB 主包拆成几个百 KB 级别的小文件用户进任意页面只下载 framework 该路由相关部分未改动依赖的缓存命中率从全失效变成大部分保留。另外两个备选策略按需选bigVendors把所有 node_modules 合进一个 vendors 文件适合依赖稳定的老项目depPerChunk每个 npm 包一个 chunk粒度最细但请求数多。不确定就从granularChunks开始。按需加载大型组件静态 import 的重组件会把它的依赖链整个拉进主包。改成动态 import 后该组件及其独占依赖自动变成独立 chunk用户触达时才加载import { lazy, Suspense } from react; const Editor lazy(() import(/components/Editor)); Suspense fallback{Loading /} Editor / /Suspense优先拆引用了大第三方库的组件比如引用了 echarts、monaco、antd 全部表格组件的页面区块。判断标准很简单用 ANALYZE 看它独占的依赖体积超过 200KB 就值得拆。官方对这条路径的完整说明见 docs/docs/blog/code-splitting.md。用 chainWebpack 自定义拆包规则内置策略不满足时比如想把某个私有大库单独抽出去或控制 chunk 命名直接干预 webpack 的 splitChunksexport default { chainWebpack(memo) { memo.optimization.splitChunks({ cacheGroups: { vendors: { test: /[\\/]node_modules[\\/]/, name: vendors, priority: -10, }, }, }); }, };priority: -10让它低于内置 cacheGroup 优先级避免和granularChunks抢模块。调完记得再跑一次ANALYZE1 umi build对比确认没有把本来异步的模块塞回主包。配套技巧服务端开启 Brotli 或 Gzip产物体积不变传输体积一般降 70% 左右任何优化都要先有这一步首屏关键 chunk 用link relpreload提前发起当路由 chunk 体积大于 100KB 且影响首屏时静态资源走 CDN让 umi.js 之外的字体、图片不占用源站带宽分析脚本、埋点等放document.ejs里延迟加载它们不进首屏链路永远异步定期检查锁文件避免依赖版本漂移让 vendors 缓存频繁失效每次升级大依赖后对比一次构建产物体积效果验证优化前后各构建一次用三个数字对比主包体积ls -lh dist/*.js看 umi.js 从 2.6MB 降到多少通常granularChunks能压到 500-800KB首屏耗时Lighthouse 或 DevTools 里对比 TTI弱网Fast 3G下一般缩短 30%-60%缓存命中改一个页面后重新构建用哈希文件名对比哪些 chunk 没变没变的文件占比越高二次访问越快如果某次改动后主包反而变大说明有新代码被同步 import 进主包回到 ANALYZE 找新增模块把它改成动态 import 即可。建议按ANALYZE 定位 → granularChunks → 动态导入的顺序落地每步之间跑一次构建对比数据。先拿到最大收益的一行配置再逐块啃剩下的体积比一次性重构所有 import 更稳。【免费下载链接】umiA framework in react community ✨项目地址: https://gitcode.com/GitHub_Trending/um/umi创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
