React.lazy未提升Lighthouse/PageSpeed评分，是否存在问题？

1. 懒加载触发时机完全错了 #

别以为用了React.lazy/dynamic就会自动在页面加载后期加载组件。如果你的懒加载组件在首屏可视区域内，或者它的父组件在首屏渲染时就被渲染了，浏览器会和加载首屏资源一起请求这个组件的chunk，和直接引入没区别，根本不会减少首屏资源体积。

• 举个例子：你把首屏的一个列表项用lazy包裹，那这个组件的chunk还是会在页面初始加载时被请求，完全起不到延迟加载的作用。
• 正确姿势：只有当组件进入可视区域（用Intersection Observer监听）、用户点击按钮/滚动到特定位置时，再渲染这个懒加载组件。

2. 代码分割粒度不合理 #

如果你的懒加载chunk体积太小，或者把一堆无关组件打包到同一个chunk里，Lighthouse不会认为这是有效优化：

• 比如把一个1KB的组件单独拆成chunk，额外的网络请求开销甚至会抵消加载收益。
• 应该优先对非首屏、体积较大的组件（比如复杂图表、长表单模块）做分割，或者直接按路由维度做代码分割（这也是最常见的有效懒加载场景）。

3. 你优化的是非首屏资源，工具本来就不统计 #

Lighthouse和PageSpeed Insights核心关注的是首屏加载性能。如果你懒加载的组件本来就不在首屏渲染路径里，那这部分优化不会体现在首屏相关的评分指标里——因为工具检测的是用户首次打开页面时的加载情况，非首屏资源的延迟加载本来就不会影响首屏评分。

4. 其他性能瓶颈盖过了懒加载的收益 #

如果你的页面本身有更大的性能问题（比如首屏一堆未压缩的大图、阻塞渲染的CSS/JS、慢到离谱的接口请求），懒加载带来的那点资源体积减少根本不足以让评分提升。比如首屏图片占了80%的加载时间，你优化一个10KB的组件懒加载，评分自然没变化。

5. React懒加载的实现细节出问题了 #

• 如果你用Next.js的dynamic，没设置ssr: false（当组件不需要服务端渲染时），服务端可能会提前加载组件，导致首屏资源没减少。
• 检查Suspense的位置：如果Suspense直接包裹了首屏组件，那懒加载组件的加载状态不会影响首屏，但如果Suspense的父组件在首屏渲染，还是会触发chunk提前加载。

怎么验证？ #

• 打开浏览器DevTools的Network面板，刷新页面，看懒加载组件的chunk什么时候请求：如果是页面加载完后（或用户操作后）才请求，说明懒加载生效；如果和首屏资源一起加载，那就是触发时机错了。
• 看Lighthouse的Performance报告，查"Unused JavaScript"部分，如果懒加载的chunk被标记为未使用，说明你提前加载了根本不需要的资源。

内容的提问来源于stack exchange，提问作者aa bb