UmiJS 4 打包优化指南umi.js 太大导致加载缓慢如何用三步代码分割解决【免费下载链接】umiA framework in react community ✨项目地址: https://gitcode.com/GitHub_Trending/um/umi用 UmiJS 4 跑完umi build发现 dist 里的 umi.js 动辄两三百 KB 甚至上 MB首屏要等好几秒。这篇指南带你用 Umi 4 内置的codeSplitting配置把主包切开配合动态导入把大依赖挪出去最后用 ANALYZE 工具验证产物三步把加载速度拉回来。为什么慢先搞懂浏览器卡在哪代码分割code splitting说白了就是「把一个大文件切成很多小文件用到哪个才下载哪个」。打个比方浏览器加载你的应用就像去自助餐厅吃饭。默认情况是服务员一次性把整桌菜全端上来——你明明只想吃一碗面却要先等满桌菜凉透才能动筷子。文件越大下载越久浏览器解析 JavaScript 的 CPU 时间也越长用户看到的就是一片白屏。更扎心的是缓存整桌菜是一个盘子一个 umi.js你只换了一道凉菜改了一行业务代码用户也得把整盘重新下单。改成小碟装菜之后没变的菜直接走缓存只有改过的碟子需要重新传菜。这就是为什么「切得对」比「切得多」更重要——切法决定了缓存命中率。三步落地法第一步开启 granularChunks 粒度化分块在配置文件里加一段codeSplitting这是 Umi 4 内置的策略开关不用手写 webpack// config/config.ts 或 .umirc.ts export default defineConfig({ codeSplitting: { jsStrategy: granularChunks, }, });granularChunks是三种策略里的中间档它把 react、react-router 这类框架库单独打成 framework 块把超过 160KB 的大依赖各自独立被两个以上页面共享的代码抽成 shared 块。官方文档的结论也很直接无特殊场景建议用这个。三种策略的差异可以看 codeSplitting 配置说明策略源码在 packages/preset-umi/src/features/codeSplitting/。改完你会看到什么变化dist 目录里不再只有一个巨无霸 umi.js而是出现 framework.js、各依赖的独立 chunk 和若干 shared 块主文件明显瘦身。第二步动态导入把大组件挪出主包路由级拆分是 Umi 默认行为每个页面本身就是独立 chunk但页面里引用的第三方库比如 monaco 编辑器、图表库如果写在模块顶层 import就会跟着主包走。改成动态导入import { lazy, Suspense } from react; // 引用了重型依赖的组件单独拆出去按需加载 const ChartPanel lazy(() import(./components/ChartPanel)); export default function() { return ( Suspense fallback{divloading.../div} ChartPanel / /Suspense ); }别漏了Suspense它是动态导入的搭档负责在 chunk 下载完成前显示加载状态。更多细节参考 官方代码拆分指南完整用法可看 ant-design-pro 示例配置granularChunks chainWebpack 的组合。改完你会看到什么变化那个大依赖从首屏关键路径上消失只有用户真的访问到用到它的页面时才发起请求首屏要下载的字节数肉眼可见地减少。第三步用 ANALYZE 验证产物构成别凭感觉判断效果Umi 内置了产物分析工具ANALYZE1 umi build构建完成后会自动打开一个可视化页面treemap 树状图哪个块占多大、大依赖被谁引用一目了然。想换端口可以用ANALYZE_PORT环境变量详见 环境变量文档。改完你会看到什么变化你手里有了一张「证据链」——优化前后的 treemap 摆在一起主块变小、依赖块独立这件事不再是口头描述而是可以贴进周报的数字。容易踩的坑坑一配了 codeSplitting开发环境却毫无变化现象dev server 里请求列表没变化怀疑配置没生效。原因策略源码里第一行就是if (api.env ! production) return;代码分割只在生产构建时生效。怎么救别在 dev 里找效果直接umi build看产物或ANALYZE1 umi build。坑二文件数量暴涨请求多到焦虑现象dist 里多了几十个shared-xxx.js担心 HTTP 请求太多拖慢加载。原因granularChunks 会把被两个以上页面共享的模块抽成独立块页面越多、公共代码越多块越多。怎么救现代浏览器 HTTP/2 下几十个并发请求不是问题如果你的部署环境还是 HTTP/1.1 且页面特别多可以换成bigVendors所有 node_modules 合成一个大 vendors 块文件少但单文件大或depPerChunk按包名拆分在体积和请求数之间再权衡。坑三动态导入后页面白屏或闪一下空白现象加了lazy之后组件区域空白控制台可能有 React 报错。原因忘了用Suspense包裹React 不知道 chunk 加载期间该显示什么。怎么救lazy和Suspense是绑定使用外层套上Suspense fallback{...}即可顺带一提Umi 还支持用约定式loading.tsx自定义页面级加载动画。优化前后对比以一个中型管理后台为例典型的收益区间是这样的主文件体积通常能下降一半左右因为它剩下的只是框架核心和首屏必需代码大依赖图表、编辑器之类从「每次必下载」变成「用到才下载」首屏关键请求的总字节数明显缩水。缓存方面改动一行业务代码后用户再次访问时 framework 块、第三方依赖块全部命中缓存只需下载变化那一个页面块——从「整盘重传」变成「只传一盘」。具体数字因项目而异所以第三步的 ANALYZE 不是可选项是让这些数据落到你项目上的必要动作。一句话收尾记住这个顺序切开granularChunks→ 挪走lazy 动态导入→ 验证ANALYZE1先分块、再挪大件、最后用 treemap 交差。【免费下载链接】umiA framework in react community ✨项目地址: https://gitcode.com/GitHub_Trending/um/umi创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 UmiJS 4 打包优化指南：umi.js 太大导致加载缓慢，如何用三步代码分割解决
UmiJS 4 打包优化指南umi.js 太大导致加载缓慢如何用三步代码分割解决【免费下载链接】umiA framework in react community ✨项目地址: https://gitcode.com/GitHub_Trending/um/umi用 UmiJS 4 跑完umi build发现 dist 里的 umi.js 动辄两三百 KB 甚至上 MB首屏要等好几秒。这篇指南带你用 Umi 4 内置的codeSplitting配置把主包切开配合动态导入把大依赖挪出去最后用 ANALYZE 工具验证产物三步把加载速度拉回来。为什么慢先搞懂浏览器卡在哪代码分割code splitting说白了就是「把一个大文件切成很多小文件用到哪个才下载哪个」。打个比方浏览器加载你的应用就像去自助餐厅吃饭。默认情况是服务员一次性把整桌菜全端上来——你明明只想吃一碗面却要先等满桌菜凉透才能动筷子。文件越大下载越久浏览器解析 JavaScript 的 CPU 时间也越长用户看到的就是一片白屏。更扎心的是缓存整桌菜是一个盘子一个 umi.js你只换了一道凉菜改了一行业务代码用户也得把整盘重新下单。改成小碟装菜之后没变的菜直接走缓存只有改过的碟子需要重新传菜。这就是为什么「切得对」比「切得多」更重要——切法决定了缓存命中率。三步落地法第一步开启 granularChunks 粒度化分块在配置文件里加一段codeSplitting这是 Umi 4 内置的策略开关不用手写 webpack// config/config.ts 或 .umirc.ts export default defineConfig({ codeSplitting: { jsStrategy: granularChunks, }, });granularChunks是三种策略里的中间档它把 react、react-router 这类框架库单独打成 framework 块把超过 160KB 的大依赖各自独立被两个以上页面共享的代码抽成 shared 块。官方文档的结论也很直接无特殊场景建议用这个。三种策略的差异可以看 codeSplitting 配置说明策略源码在 packages/preset-umi/src/features/codeSplitting/。改完你会看到什么变化dist 目录里不再只有一个巨无霸 umi.js而是出现 framework.js、各依赖的独立 chunk 和若干 shared 块主文件明显瘦身。第二步动态导入把大组件挪出主包路由级拆分是 Umi 默认行为每个页面本身就是独立 chunk但页面里引用的第三方库比如 monaco 编辑器、图表库如果写在模块顶层 import就会跟着主包走。改成动态导入import { lazy, Suspense } from react; // 引用了重型依赖的组件单独拆出去按需加载 const ChartPanel lazy(() import(./components/ChartPanel)); export default function() { return ( Suspense fallback{divloading.../div} ChartPanel / /Suspense ); }别漏了Suspense它是动态导入的搭档负责在 chunk 下载完成前显示加载状态。更多细节参考 官方代码拆分指南完整用法可看 ant-design-pro 示例配置granularChunks chainWebpack 的组合。改完你会看到什么变化那个大依赖从首屏关键路径上消失只有用户真的访问到用到它的页面时才发起请求首屏要下载的字节数肉眼可见地减少。第三步用 ANALYZE 验证产物构成别凭感觉判断效果Umi 内置了产物分析工具ANALYZE1 umi build构建完成后会自动打开一个可视化页面treemap 树状图哪个块占多大、大依赖被谁引用一目了然。想换端口可以用ANALYZE_PORT环境变量详见 环境变量文档。改完你会看到什么变化你手里有了一张「证据链」——优化前后的 treemap 摆在一起主块变小、依赖块独立这件事不再是口头描述而是可以贴进周报的数字。容易踩的坑坑一配了 codeSplitting开发环境却毫无变化现象dev server 里请求列表没变化怀疑配置没生效。原因策略源码里第一行就是if (api.env ! production) return;代码分割只在生产构建时生效。怎么救别在 dev 里找效果直接umi build看产物或ANALYZE1 umi build。坑二文件数量暴涨请求多到焦虑现象dist 里多了几十个shared-xxx.js担心 HTTP 请求太多拖慢加载。原因granularChunks 会把被两个以上页面共享的模块抽成独立块页面越多、公共代码越多块越多。怎么救现代浏览器 HTTP/2 下几十个并发请求不是问题如果你的部署环境还是 HTTP/1.1 且页面特别多可以换成bigVendors所有 node_modules 合成一个大 vendors 块文件少但单文件大或depPerChunk按包名拆分在体积和请求数之间再权衡。坑三动态导入后页面白屏或闪一下空白现象加了lazy之后组件区域空白控制台可能有 React 报错。原因忘了用Suspense包裹React 不知道 chunk 加载期间该显示什么。怎么救lazy和Suspense是绑定使用外层套上Suspense fallback{...}即可顺带一提Umi 还支持用约定式loading.tsx自定义页面级加载动画。优化前后对比以一个中型管理后台为例典型的收益区间是这样的主文件体积通常能下降一半左右因为它剩下的只是框架核心和首屏必需代码大依赖图表、编辑器之类从「每次必下载」变成「用到才下载」首屏关键请求的总字节数明显缩水。缓存方面改动一行业务代码后用户再次访问时 framework 块、第三方依赖块全部命中缓存只需下载变化那一个页面块——从「整盘重传」变成「只传一盘」。具体数字因项目而异所以第三步的 ANALYZE 不是可选项是让这些数据落到你项目上的必要动作。一句话收尾记住这个顺序切开granularChunks→ 挪走lazy 动态导入→ 验证ANALYZE1先分块、再挪大件、最后用 treemap 交差。【免费下载链接】umiA framework in react community ✨项目地址: https://gitcode.com/GitHub_Trending/um/umi创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考