CoreWebVitals 评估与 PageSpeen Insights 性能等级之间存在差异的原因是什么？

Question

在使用 PageSpeed Insights 测试测试不同网站时，我遇到了相同的现象，我自己无法解释：

有多个 URL 通过了 Core Web Vitals 评估，但全部为红色指标且性能等级较低，如屏幕截图所示：

是的，我知道，Core Web Vitals 评估是通过汇总过去 28 天内 Chrome 用户的加载时间来计算的。但这对我来说仍然无法解释：加载指标在 Core Web Vitasl 评估和性能诊断之间怎么会有如此巨大的差异？

• LCP：诊断率高出约七倍
• FCP：诊断率高出近三倍
• CLS：诊断率高出五倍以上

并且：这不是单一案例或单一 URL。我经常看到这种行为，经常认为这可能是意外。

有人可以向我解释一下这些差异吗？

PS：这种差异是有一定意义的，这可以很好地解释它，但我对此非常怀疑。其含义是：

• Core Web Vitals 评估仅检查首屏区域、页面的第一个初始视口，
• PageSpeed Insigts 性能测试显示整个页面的数据，直到

  onLoad

  事件。

Answer 1

存在许多可能的差异，其中大部分都在 Goggle Chrome 团队的指南中进行了介绍，例如在 Core Web Vitals 工作流程与 Google 工具文档以及我们的每个优化指南（LCP、CLS）中）。完全披露，我帮助写了这些。

首先，正如里克在评论中提到的，确保你正在进行同类比较。通常，真实用户数据不可用于特定的 URL，因此顶部部分可能针对整个源，而不仅仅是该 URL。

接下来，Lighthouse 在特定条件下进行模拟负载。它还仅对折叠内容以上进行冷加载，而不进行交互。

具体查看此示例（并假设它是 URL 级数据，或者至少代表该 URL）：

对于真实用户来说，LCP 和 FCP 可能比 Lighthouse 更快（或更慢），具体取决于：

• Lighthouse 条件对您的用户环境的代表性如何。 Lighthouse 在全球范围内使用相当有代表性的设置，但你们的用户可能都基于更快或更慢的设备。
• 冷加载访问与重复访问/部分缓存访问。如果用户重新访问页面，那么由于资源被缓存，它通常会加载得更快（特别是当页面位于内存中时返回时）。或者，如果访问者访问主页，然后访问辅助页面，如果从主页重用这些资源，他们可能会缓存许多资源。
• 如果某个页面缓存在您的基础设施中（例如在 CDN 中），那么它在重复 Lighthouse 运行时可以快速提供服务，但对于只偶尔访问一次的用户来说速度较慢。
• 用户如何访问您的网站。如果点击 add 或 bit.ly 链接，他们可能会经历重定向，这可能会减慢速度。 Lighthouse 通常根据实际 URL 进行测试。
• 用户距离有多远。 PSI 尝试从您位于美国、欧洲和亚洲的数据中心进行测试。如果您的服务器位于欧洲并且 PSI 使用欧洲数据中心，但您的大部分用户在澳大利亚，那么真实用户可能会获得与 Lighthouse 测试截然不同（更慢）的体验。
• 用户获得的内容是否不同？例如，Lighthouse 将加载缓慢的 cookie 横幅显示为 LCP 元素，但许多用户没有看到它，因为已经接受了它？

对于 CLS 差异，此处通常表示加载后 CLS，如我们的指南中所讨论的那样。 CLS 是在页面的整个生命周期中进行测量的，虽然 CLS 确实在页面加载期间通常很糟糕（这是 Lighthouse 测量的全部内容），但有些情况可能会在以后发生。例如，如果您滚动，延迟加载的图像或广告就会在没有保留空间的情况下弹出。我也经常看到粘性标题实施不当的滚动问题。如果与页面交互发生在 500 毫秒的交互宽限期之后，也可能导致 CLS。 总而言之，Lighthouse 可能代表也可能不代表真实用户如何体验您的网站。

这是否意味着 Lighthouse 没有用了？绝对不！ Lighthouse 对于识别潜在的性能问题非常有用。对于加载问题（FCP 和 LCP），这些问题可能比现实情况更糟糕，因为它对页面进行简单的冷加载。但优化最坏的情况将使您的网站受益！

对于 CLS（对于 INP 也类似），这更多的是对简单页面加载功能的限制。因此，在匹配的地方，您可以使用它的建议来改善现实生活中的指标。如果没有，您至少已经排除了负载问题作为可能的原因，并且可以看看还有哪些地方可能会很慢。