umi 代码分割实战4 个让首屏提速的配置点【免费下载链接】umiA framework in react community ✨项目地址: https://gitcode.com/gh_mirrors/umi8/umiumi 内置了代码分割机制页面按路由切块、组件可动态导入、公共代码可拆出、第三方库可外置。这篇按排查的思路讲一遍这 4 个点分别怎么配置、坑在哪。上周有同事甩来一个截图应用打开要 5 秒。打开 Network 面板一看罪魁祸首不是某个接口慢而是主入口 JS 有 1.8MB——所有页面、图表库、甚至 moment 的几十个 locale 全挤在一个文件里。umi 其实早就把分割的口子留好了只是默认状态下你只用了其中一部分。下面按先分页面、再分组件、再拆公共、最后外置的顺序逐个过。1. 路由分割先确认每个页面是不是独立 chunk先给结论umi 在构建时会把路由表生成一份 router 代码由 FilesGenerator 生成其中每个页面的 component 都被转写成import()webpack 因此把每个页面单独打成 async chunk。产物里文件名遵循这个规则源码output: { filename: [name].[hash].js, // 主入口 chunkFilename: [name].[hash].async.js // 各页面/动态块 }效果是用户访问/order浏览器只拉umi.xxx.js框架 公共依赖和order.xxx.async.js不会碰/report的代码。如果产物里所有页面都挤在umi.xxx.js一个文件里大概率是有人配了disableDynamicImport——它会把import()全部同步化所有代码合并回主包配置文档。这个选项是给离线场景准备的常规项目别开。2. 组件级分割让大组件自己变成一块 chunk页面 chunk 独立还不够首页里挂了一个带复杂表格的组件它照样被打包进首页代码。这类不首屏必须的重型组件用 umi 自带的 dynamic 包一层import dynamic from umi/dynamic; const OrderTable dynamic(() import(./OrderTable)); export default function OrderPage() { return OrderTable initialRows{12} /; }import(./OrderTable)被 webpack 切成一块独立 chunk首页不再为它付出体积。看 dynamic 的源码 有两点值得注意它会在组件构造时就发起加载利用页面其它模块初始化的时间窗口提前拉代码用户基本看不到加载态组件卸载后如果加载才完成它会跳过 setState避免报错。想给等待中的用户一点反馈传个loading就行const OrderTable dynamic( () import(./OrderTable), { loading: () div表格加载中…/div } );如果只是想懒加载一个模块而不是渲染组件比如等用户点导出按钮时才要 echarts直接裸写import()即可umi 的按需加载文档 docs/guide/load-on-demand.md 就是这两种写法的说明async function exportReport() { const echarts await import(echarts); // 用 echarts 画导出图… }3. 拆公共代码与长效缓存路由块各自独立后下一层问题是缓存框架代码React、路由、全局组件只会被动更新却和某个页面混在 chunk 里时页面一变缓存就失效。umi 暴露了commons配置底层逐个挂成 webpack 3 的CommonsChunkPlugin实现位置// .umirc.js export default { commons: [vendors, common], };这会强制把公共依赖收敛进vendors块。再配合hash配置打开产物文件名带内容哈希就拿到长效缓存vendors.xxx.js不随业务代码变化用户二次访问走缓存只有真正改动的页面块重新下载。代价是 hash 变了的首次访问要重新拉 vendors用版本刷新机制兜底即可。4. 外置第三方库体积直接归零拆块只能挪体积外置才是消体积。externals直接透传给 webpack配置文档export default { externals: { lodash: _, }, };告诉 webpack 别打包 lodash改成运行时读全局_再在 HTML 模板里引入 CDN 上的 lodashbundle 里这部分体积归零。两个注意CDN 有风险只外置稳定、不频繁升级的大依赖moment 这类带大量 locale 的库umi 有现成开关ignoreMomentLocale 配置 会挂 webpack 的 IgnorePlugin把 locale 文件从包里剔除属于免费的优化。收尾一条命令 一份检查清单改完别凭感觉跑一次带分析的构建ANALYZE1 umi buildumi 会在 8888 端口起 bundle 分析页实现直接看哪个 chunk 最大、依赖指向哪里。然后对着清单过一遍构建产物中每个路由都有对应的.async.js而不是全在umi.xxx.js里主入口只含框架 公共依赖表格、图表这类重型组件已经dynamic/import()包掉稳定大依赖走externals CDNignoreMomentLocale已开hash已开配合版本刷新报告里 200KB 的 chunk 有明确去向拆掉或外置把每次请求只下载当前需要的代码做到位首屏提速是顺手的事。【免费下载链接】umiA framework in react community ✨项目地址: https://gitcode.com/gh_mirrors/umi8/umi创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 umi 代码分割实战：4 个让首屏提速的配置点
umi 代码分割实战4 个让首屏提速的配置点【免费下载链接】umiA framework in react community ✨项目地址: https://gitcode.com/gh_mirrors/umi8/umiumi 内置了代码分割机制页面按路由切块、组件可动态导入、公共代码可拆出、第三方库可外置。这篇按排查的思路讲一遍这 4 个点分别怎么配置、坑在哪。上周有同事甩来一个截图应用打开要 5 秒。打开 Network 面板一看罪魁祸首不是某个接口慢而是主入口 JS 有 1.8MB——所有页面、图表库、甚至 moment 的几十个 locale 全挤在一个文件里。umi 其实早就把分割的口子留好了只是默认状态下你只用了其中一部分。下面按先分页面、再分组件、再拆公共、最后外置的顺序逐个过。1. 路由分割先确认每个页面是不是独立 chunk先给结论umi 在构建时会把路由表生成一份 router 代码由 FilesGenerator 生成其中每个页面的 component 都被转写成import()webpack 因此把每个页面单独打成 async chunk。产物里文件名遵循这个规则源码output: { filename: [name].[hash].js, // 主入口 chunkFilename: [name].[hash].async.js // 各页面/动态块 }效果是用户访问/order浏览器只拉umi.xxx.js框架 公共依赖和order.xxx.async.js不会碰/report的代码。如果产物里所有页面都挤在umi.xxx.js一个文件里大概率是有人配了disableDynamicImport——它会把import()全部同步化所有代码合并回主包配置文档。这个选项是给离线场景准备的常规项目别开。2. 组件级分割让大组件自己变成一块 chunk页面 chunk 独立还不够首页里挂了一个带复杂表格的组件它照样被打包进首页代码。这类不首屏必须的重型组件用 umi 自带的 dynamic 包一层import dynamic from umi/dynamic; const OrderTable dynamic(() import(./OrderTable)); export default function OrderPage() { return OrderTable initialRows{12} /; }import(./OrderTable)被 webpack 切成一块独立 chunk首页不再为它付出体积。看 dynamic 的源码 有两点值得注意它会在组件构造时就发起加载利用页面其它模块初始化的时间窗口提前拉代码用户基本看不到加载态组件卸载后如果加载才完成它会跳过 setState避免报错。想给等待中的用户一点反馈传个loading就行const OrderTable dynamic( () import(./OrderTable), { loading: () div表格加载中…/div } );如果只是想懒加载一个模块而不是渲染组件比如等用户点导出按钮时才要 echarts直接裸写import()即可umi 的按需加载文档 docs/guide/load-on-demand.md 就是这两种写法的说明async function exportReport() { const echarts await import(echarts); // 用 echarts 画导出图… }3. 拆公共代码与长效缓存路由块各自独立后下一层问题是缓存框架代码React、路由、全局组件只会被动更新却和某个页面混在 chunk 里时页面一变缓存就失效。umi 暴露了commons配置底层逐个挂成 webpack 3 的CommonsChunkPlugin实现位置// .umirc.js export default { commons: [vendors, common], };这会强制把公共依赖收敛进vendors块。再配合hash配置打开产物文件名带内容哈希就拿到长效缓存vendors.xxx.js不随业务代码变化用户二次访问走缓存只有真正改动的页面块重新下载。代价是 hash 变了的首次访问要重新拉 vendors用版本刷新机制兜底即可。4. 外置第三方库体积直接归零拆块只能挪体积外置才是消体积。externals直接透传给 webpack配置文档export default { externals: { lodash: _, }, };告诉 webpack 别打包 lodash改成运行时读全局_再在 HTML 模板里引入 CDN 上的 lodashbundle 里这部分体积归零。两个注意CDN 有风险只外置稳定、不频繁升级的大依赖moment 这类带大量 locale 的库umi 有现成开关ignoreMomentLocale 配置 会挂 webpack 的 IgnorePlugin把 locale 文件从包里剔除属于免费的优化。收尾一条命令 一份检查清单改完别凭感觉跑一次带分析的构建ANALYZE1 umi buildumi 会在 8888 端口起 bundle 分析页实现直接看哪个 chunk 最大、依赖指向哪里。然后对着清单过一遍构建产物中每个路由都有对应的.async.js而不是全在umi.xxx.js里主入口只含框架 公共依赖表格、图表这类重型组件已经dynamic/import()包掉稳定大依赖走externals CDNignoreMomentLocale已开hash已开配合版本刷新报告里 200KB 的 chunk 有明确去向拆掉或外置把每次请求只下载当前需要的代码做到位首屏提速是顺手的事。【免费下载链接】umiA framework in react community ✨项目地址: https://gitcode.com/gh_mirrors/umi8/umi创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考