PageSpeed Insights移动端TBT偶发过高致评分骤降问题咨询

这不是PageSpeed Insights（PSI）检测不稳定导致的误报。你遇到的10%概率低分，本质是React应用存在卡在性能阈值边缘的长主线程任务，PSI云检测环境的资源波动只是把这个隐性问题放大了。

正常PSI共享云检测实例的CPU、网络调度波动只会带来3-5分的分数浮动，一旦出现10分以上的掉分，必然是页面本身存在临界状态的性能问题。从你的检测数据看，9次高分场景下TBT都稳定在合格线内，一旦检测实例出现临时资源抢占，JS执行速度下降，首屏的同步执行任务就会跨过50ms的长任务判定阈值，直接推高TBT；同时主线程阻塞会拖慢LCP渲染，最终导致分数暴跌。
从异常时的长任务明细可以看到，所有超长任务都指向同一个主包main.39443e3e.js和站点根路径，没有第三方脚本的异常占用，问题完全出在React应用自身的首屏初始化逻辑上。

• 优先排查React水合/首屏挂载阶段的同步逻辑
  如果你使用React 17及以下版本，或是React 18未开启并发模式，首屏挂载时所有同步执行的useEffect、未做缓存的大计算量渲染、一次性挂载的长列表、未做懒加载的重型组件（富文本编辑器、图表库、大型状态管理库初始化）都会挤在主线程的首个执行阶段运行。这些逻辑在本地高性能设备上可能刚好执行40余ms，达不到长任务阈值，一旦CPU资源紧张就会变成数百ms的长任务。你可以在本地Chrome DevTools的Performance面板中将CPU节流调到4-6倍速，连续刷新10次以上录制执行轨迹，就能稳定复现这些长任务，直接查看调用栈即可定位到具体组件或逻辑。
• 校验主包代码分割是否生效
  所有长任务都落在main主包上，基本可以判定首屏加载了大量非必要代码：比如未做路由懒加载的其他页面逻辑、首屏视口外不需要即时渲染的弹窗/组件、未按需引入的全量工具库/组件库（比如全量moment、未做tree-shaking的UI库），这些代码都会在主包解析完成后同步执行，很容易出现执行时长卡在阈值的问题。可以用打包分析工具扫描主包构成，把非首屏必须的代码全部拆出，通过动态import做懒加载。
• 排查非确定性执行的同步逻辑
  重点检查首屏阶段是否存在执行时长不固定的逻辑：比如无缓存的大体积JSON解析、同步读取超大容量的localStorage/IndexedDB数据、埋点SDK初始化时的批量数据处理、按条件触发的非固定计算逻辑，这类逻辑的执行时长波动大，是偶发长任务的高发区。
• 预留足够的性能波动余量
  如果要彻底消除偶发低分，不要把首屏同步任务的执行时长卡着50ms的长任务阈值做优化，要将本地高性能环境下的单个同步任务执行时长控制在30ms以内，给检测环境、真实用户的中低端设备留足波动空间。可以通过时间切片、React 18的startTransition、requestIdleCallback等能力，把非首屏必须的逻辑拆成小块延后执行，避免长时间独占主线程。

不要靠反复刷新PSI碰高分交付客户。这类临界长任务在真实用户的中低端移动设备上，触发TBT超标的概率远高于10%，本质是真实存在的性能隐患，不是检测工具的误差。

内容的提问来源于stack exchange，提问作者Sid Scott