为何部分新闻网站页面性能偏低却仍通过Core Web Vitals检测？

一、印度斯坦时报网站Core Web Vitals通过但实验室性能分低的原因 #

Pagespeed Insights的结果分为两个核心数据源，这是导致看似矛盾结果的关键：

• Core Web Vitals“通过”基于真实用户数据（CrUX）：这个数据来自Chrome用户的实际访问统计，只要用户群体的第75百分位指标达标，就会显示通过。网站可能针对大多数真实用户的场景做了优化，比如：
  • 给主流设备、常规网络环境的用户提供了达标首屏加载（满足LCP要求），真实用户的交互延迟（TBT）也在可接受范围内。
  • 利用缓存策略让回头用户快速加载，这部分用户占比大，拉高了CrUX的整体达标率。
  • 核心内容优先加载，非核心资源（如广告、非首屏组件）延迟到用户交互后加载，真实用户不会感知到这些资源的加载延迟，但实验室测试会把这些资源的加载计算到TBT里。
• 实验室性能分低、LCP/TBT红警来自Lighthouse模拟测试：这是在受控的冷启动、慢网络（默认慢3G）环境下的测试结果，网站可能没针对这种极端场景优化：
  • 冷启动下没有缓存，导致首屏资源加载慢，LCP不达标。
  • 实验室测试会统计所有同步执行的脚本阻塞时间，包括那些真实用户不会触发的脚本，导致TBT数值偏高。
  • 地域节点差异：实验室测试的服务器节点和真实用户的访问节点网络条件不同，加载速度差异大。

二、Core Web Vitals评估规则的具体依据 #

首先纠正一个误解：Core Web Vitals采用的是第75百分位数值，而非简单算术平均值，它的依据包括：

• 用户体验研究结论：Google的用户体验研究表明，当至少75%的用户能获得良好的加载、交互体验时，整体用户满意度会显著提升。第75百分位的阈值能确保绝大多数用户的体验达标，而非只看平均水平。
• 避免极端值干扰：算术平均值会被极少数极端情况（比如用户在极差网络下的加载）拉低，无法反映大多数用户的真实体验。百分位统计更能体现用户群体的普遍加载性能。
• 平衡优化成本：要求100%用户达标成本极高，而第75百分位的标准既能保证大部分用户的体验，又让网站优化具备可行性。

内容的提问来源于stack exchange，提问作者Shreyansh Deep