为了减小首屏 bundle,把一堆组件都做成了 dynamic(() => import(...))。结果首屏是快了,但交互时一堆 chunk 同时请求,FCP 到可交互反而拖长了。
后来反思:dynamic 不是越多越好,得看组件是否真在首屏外、是否够大。小组件 dynamic 反而增加请求开销。
正确做法:
- 路由级别懒加载(默认就有)。
- 重型组件(编辑器、图表)单独 dynamic。
- 小组件继续静态 import。
大家有没有量化过 dynamic 的收益?
为了减小首屏 bundle,把一堆组件都做成了 dynamic(() => import(...))。结果首屏是快了,但交互时一堆 chunk 同时请求,FCP 到可交互反而拖长了。
后来反思:dynamic 不是越多越好,得看组件是否真在首屏外、是否够大。小组件 dynamic 反而增加请求开销。
正确做法:
大家有没有量化过 dynamic 的收益?
暂时没有回复。
Related
讨论
社区讨论帖,欢迎分享你的经验和观点。
讨论
分享下我现在的日常流程,不一定最优,但用着顺手。 新功能先让它在 plan 模式下出方案,我确认后再 apply;Server Action 这种容易出错的,强制它先写一个测试用例再写实现;样式部分我手写,不让它碰 Tailwind 类名(它审美不太行)。 最后一步永远是跑 pn
讨论
把一个 Pages Router 项目分批迁到 App Router,前后折腾了快半年。最大的感受是:缓存边界和 "use client" 这两件事,文档轻描淡写,实际占了 80% 的坑。 中间遇到过几次经典翻车: 客户端组件里直接 fetch ,被默认缓存导致数据不刷新。 pa
讨论
看了不少文章,还是没完全 get 到 RSC 的核心价值。表面说是 "组件在服务端跑",但 SSR 不也能在服务端跑组件吗? 我自己理解下来,主要差在两点:RSC 是 "按组件粒度" 决定跑在哪,并且它能直接访问数据源,不用再走一层 API。组件树里零 JS 下发到客户端这点确实