提问人:Evgeniy 提问时间:10/18/2023 最后编辑:Evgeniy 更新时间:10/19/2023 访问量:78
CoreWebVitals 评估和 PageSpeen Insights 性能等级之间存在差异的原因是什么?
What are causes of the differece between CoreWebVitals assessment and PageSpeen Insights performance grade?
问:
在使用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
答:
存在许多可能的差异,其中大部分在 Goggle Chrome 团队的指南中都有介绍,例如,在使用 Google 工具文档的 Core Web Vitals 工作流程以及我们的每个优化指南(LCP、CLS)中。完全披露,我帮助写了这些。
首先,正如 Rick 在评论中提到的,请确保您正在比较同类。通常,真实用户数据不适用于特定 URL,因此顶部部分可能适用于整个源,而不仅仅是该 URL。
接下来,Lighthouse 在特定条件下执行模拟负载。它还仅对上述折叠内容进行冷负载,无需交互。
具体看一下这个例子(并假设它是 URL 级别的数据,或者至少代表该 URL):
对于真实用户来说,LCP 和 FCP 可能比 Lighthouse 快得多(或更慢),具体取决于:
- Lighthouse 条件对用户环境的代表性。Lighthouse 在全球范围内使用相当受谴责的设置,但您的用户可能都基于更快或更慢的设备。
- 冷负载访问与重复访问/部分缓存访问。如果用户重新访问页面,那么随着资产的缓存,它通常会加载得更快(尤其是在页面在内存中时返回时)。或者,如果访问者访问主页,然后访问辅助页面,他们可能会缓存许多资产(如果从主页重复使用)。
- 如果一个页面缓存在您的基础架构中(例如在 CDN 中),那么它在重复的 Lighthouse 运行中会快速提供,但对于只偶尔访问它一次的用户来说会变慢。
- 用户如何访问您的网站。如果单击添加或 bit.ly 链接,他们可能会经历重定向,这可能会减慢速度。Lighthouse 通常针对实际 URL 进行测试。
- 用户距离多远。PSI 尝试从您所在的位置使用美国、欧洲和亚洲的数据中心进行测试。如果您的服务器位于欧洲,而 PSI 使用欧洲数据中心,但您的大部分用户位于澳大利亚,那么真实用户可能会获得与 Lighthouse 测试截然不同(较慢)的体验。
- 用户是否获得不同的内容?例如,Lighthouse 是否将加载缓慢的 cookie 横幅显示为 LCP 元素,但许多用户没有看到并接受它?
对于 CLS,此处的差异通常表示加载后 CLS,如我们的指南中所述。CLS 是在页面的整个生命周期内测量的,虽然 CLS 在页面加载期间确实很糟糕(这是 Lighthouse 测量的全部内容),但有些可能会在以后发生。例如,如果您滚动并且延迟加载的图像或广告在没有预留空间的情况下弹出。我也经常看到粘性标题实施不当的滚动问题。如果与页面交互发生在交互的 500 毫秒宽限期之后,也可能导致 CLS。
因此,总而言之,Lighthouse 可能代表也可能不代表真实用户如何体验您的网站。
这是否意味着灯塔毫无用处?绝对不行!Lighthouse 对于识别潜在的性能问题非常有用。对于加载问题(FCP 和 LCP),这些问题可能比现实生活更糟糕,因为它对页面进行了简单、冷的加载。但是优化最坏的情况将使您的网站受益!
对于 CLS(与 INP 类似),这更像是简单页面加载功能的限制。因此,如果匹配,您可以使用其建议来改善现实生活中的指标。如果没有,您至少已经消除了负载问题作为可能的原因,并且可以查看其他可能很慢的地方。
评论