为什么 Core Web Vitals 28 天延迟是一个误解

揭穿 Core Web Vitals 28 天延迟的误解

Core Web Vitals 数据存在 28 天延迟的说法是 Web 开发社区中常见的误解。这种观念导致了诸如“我们还要等 28 天才能看到变化”或“希望它有效；28 天后就知道了”之类的说法。然而，这种认知是不准确的，它源于对 Chrome User Experience Report (CrUX) 数据处理和呈现方式的误解。

CrUX 数据的真相！

与普遍看法相反，CrUX 数据并不存在 28 天的延迟。事实上，数据非常新鲜，通常只有大约两天的延迟。这可以通过查询 Google CrUX API 来验证，它清楚地展示了数据的时效性！

理解 28 天窗口期

混淆源于 Google 呈现 Core Web Vitals 数据的方式。用户实际看到的是过去 28 天计算的第 75 百分位值。 这种统计方法旨在提供更稳定和更具代表性的网站长期性能衡量指标，而非反映短期波动。

为什么看起来像是有延迟

使用 28 天滚动窗口计算第 75 百分位可能会制造出改进延迟显现的错觉。原因如下：

• 数据逐步替换：最初，新数据会与旧的、可能较差的性能数据混合在一起。每天的数据都会被添加到 28 天的性能窗口中，同时最旧的一天数据会被移除。完全替换所有数据需要整整 28 天。
  
• 百分位计算：由于使用的是第 75 百分位，需要足够多的改进数据点才能显著移动这个指标。这可能看起来违反直觉，但你不能用思考平均值的方式来思考百分位分数。关键在于，面对突然的波动，第 75 百分位可能具有“抗变化性”。

可以这样理解： 你有一个装着 28 颗红色弹珠的盒子。每天你取出一颗旧的红色弹珠，换入一颗新的绿色弹珠。完全刷新整个盒子需要整整 28 天，但从来没有任何延迟！

盒子变成大部分是绿色（第 75 百分位）的速度取决于里面已有多少红色弹珠。如果红色弹珠很多，变绿的时间就会更长。但如果红色弹珠较少，盒子就会更快变绿。

对 Web 开发者的启示

理解这一机制对 Web 开发者和网站所有者有重要启示：

• 持续监控：与其等待 28 天才能看到结果，不如定期监控你的 Core Web Vitals，最好使用能够按每日间隔计算第 75 百分位的 RUM 跟踪。
  
• 渐进式改进：即使是小的改进也能随着时间推移逐渐推动第 75 百分位的变化。
• 耐心与坚持：虽然你可能不会在报告的指标中看到立竿见影的剧变，但持续的改进最终会被反映出来。