性能修复上线后，为什么跑分变好而真实用户数据还没变？

刚上线一个性能修复，Lighthouse 数字变好了，PageSpeed Insights 的真实用户区域却还没有明显变化。这不一定表示修复无效，也不能据此宣布所有访客已经变快。两部分数据回答的问题不同，复盘时先把统计对象、时间和访问条件对齐。

先确认看到的是哪种数据

实验室测试是在指定设备、网络与测试位置下运行的一次加载或一组操作。真实用户数据来自实际访问，混合了不同设备、网络、缓存状态与使用路径。web.dev 的实验室与现场数据差异说明强调：现场数据是一种分布，不能把其中的一个统计值当作每位访客的体验。

还要区分页面级与来源级报告。若工具展示的是整个来源的数据，就不能把变化完全归给刚修改的一个 URL。记录报告标明的范围，不要只截取中间那个数字。

上线记录要能对应到观察窗口

保存发布时间、受影响模板、资源版本和变更内容。CrUX 常见报告使用 28 天窗口，刚上线时里面仍包含修复前的访问。随着新数据进入，旧数据逐渐移出；不是必须等到第 28 天才可能看到任何变化。

如果已有合适的自建真实用户监测，可以在其覆盖范围内按版本和时间比较。但自建监测与 CrUX 的人群、采样及实现可能不同，不能把两边数值混成一条连续曲线。缺少可靠样本时，应写“仍在观察”，而不是强行判定通过或失败。

一次具体的对比应该怎样做

以下是流程示例，不是实测结果。假设只修改了文章页首图：

1. 选同一文章 URL，保持实验室设备、网络档位和测试方式一致，重复运行以了解波动。
2. 确认实际加载了新资源，并检查 LCP 元素是否仍是那张图；不同视口可能把不同内容识别为最大元素。
3. 在真实数据中查看对应页面或模板的移动、桌面分组，注明样本范围与窗口。
4. 把首访与回访、地区或版本差异作为可用线索，不为解释结果而凭空补充无法取得的维度。

例如，缓存已命中的回访者和首次打开页面的访客，加载条件可能不同。单次空缓存测试很好用，但不能代表两类访问的实际比例。WordPress 团队可进一步阅读光算的实验室分数与真实数据的对照说明，用于建立报告口径清单。

把“本地改善”和“用户改善”分开写

实验室复测支持的结论可以是：“在本次固定条件下，指定页面的加载指标改善。”真实用户观察支持的结论，则应附上人群范围、时间窗口与对应指标。两个结论可以先后成立，不需要为了汇报简洁而合并。

如果真实数据反而变差，先核对流量组成、新增脚本、页面版本和测试覆盖，而不是立刻回滚已确认有效的资源修改。加载之外的点击与滚动场景也可能产生新问题；常规加载跑分没有覆盖的部分，要另行复现。最后仍应检查业务功能，性能数字改善不能证明表单、购物车或导航工作正常。