PageSpeed Insights 现在跑的是 Lighthouse 13.6.0。这个版本改了慢速网络的模拟方式，页面一行代码没动，分数也可能往上跳一截。
PageSpeed Insights 现在跑的是 Lighthouse 13.6.0。这个版本改了慢速网络的模拟方式，页面一行代码没动，分数也可能往上跳一截。Chrome 团队的 Barry Pollard 在 11 月 2 日确认了这次切换，措辞是“更准，通常也更高”。
改的是模拟，不是你的站
Lighthouse 默认用满速加载页面，再用 Lantern 模型推算慢网下的表现。13.6 动了两处：判断一个请求是否阻塞渲染，从“看 fetch priority”改成“读 Chrome 自己给的 renderBlockingStatus 标签”，优先级只在缺标签时兜底；当 LCP 元素是与首屏内容同一帧渲染的文字时，模拟 LCP 改为用算 FCP 的那批请求和任务来推，而不是把 LCP 之前所有请求都算进去。
顺带还有几项：HTTP/3 按多路复用建模，修正了模拟 LCP 的分段计算，改进了源站 RTT、吞吐估算和重定向处理。官方说这不是 SPA 专属改动，但 JS 重的站更容易受影响。
开发者实测的涨幅
react.dev 之前报 LCP 约 7 秒、TBT 约 2 秒，更新后变成 1.1 秒和 10 毫秒，性能分满分；有开发者说部分 Framer 站点涨了 20 到 30 分。这些都是个人反馈，不是 Google 的统计，覆盖面也只有几个站，但当参考够用了——一个以文字为首屏 LCP 的页面，在旧模型下被系统性低估。
这也解释了为什么很多“明明很快”的站在 PSI 上分数难看：不是站的问题，是模型把不该算的请求算进了关键路径。
怎么区分工具变化和真实优化
先看版本号。每份 PSI 报告都在模拟设备旁边标着 Lighthouse 版本，只有版本一致的两份报告才能对比。13.6 之前和之后的分数，本质上是两套模拟，直接相减没有意义。
再看现场数据。PSI 报告里的 CrUX 部分是最近 28 天真实 Chrome 访问的聚合，跟实验室模拟是两套数据。实验室分数涨了、CrUX 的 LCP 没动，说明用户那边的体验没变，别拿去汇报“性能提升”。
时间点上还有一处要注意：13.6 预期随 Chrome 159 进 DevTools，稳定版排在 12 月 8 日。在那之前，本地 Chrome 跑的 Lighthouse 和 PSI 用的可能不是同一个版本，对比时容易得出相反结论。
对站长的实际影响
如果你在给客户做性能报表，这两天最该做的是在图表上标一条竖线，写明“11 月 2 日工具切换”，否则季度汇报里会出现一个解释不清的台阶。有 KPI 挂在 PSI 分数上的，也要提前说明这一截涨幅不来自开发。
真正该优化的还是那几项：图片和字体的加载优先级、首屏文字不要等 JS、服务端响应时间、第三方脚本延后。工具会给分数，用户只给留存，这两件事从来不是一回事。
另外 13.6 还改了几处小地方：CLI 支持一次跑多个 URL 和 --fail-fast，报告默认文件名带上路径；robots.txt 和 llms.txt 审计遇到 429 会判失败。站内有 robots.txt 返回 429 的，顺手修一下。
本文根据公开报道整理，主要参考：Elsop《PageSpeed Insights Now Runs Lighthouse 13.6》（2026-11-02）。
