了解为何监控 Core Web Vitals 指标的工具可能会报告不同的数值，以及如何解读这些差异。
Google 提供了许多工具，帮助网站所有者监控其 Core Web Vitals 分数。这些工具主要分为两类：
- 报告实验室数据的工具 - 在具有预定义设备和网络设置的受控环境中收集的数据。
- 报告现场数据的工具 - 从访问您网站的真实用户那里收集的数据。
问题在于，有时实验室工具报告的数据与现场工具报告的数据可能大相径庭！您的实验室数据可能表明您的网站性能良好，但您的现场数据却表明它需要改进。或者，您的现场数据可能表明您的所有页面都很好，但您的实验室数据可能会报告非常低的分数。
以下来自 web.dev 的 PageSpeed Insights 报告的真实示例表明，在某些情况下，实验室数据和现场数据在所有 Core Web Vitals 指标中可能都存在差异
工具之间的差异是开发者感到困惑的一个可以理解的来源。这篇文章解释了可能存在这些差异的主要原因（通过具体示例涵盖了每个 Core Web Vitals 指标），以及当您在页面上发现差异时该怎么做。
实验室数据与现场数据
要理解为什么实验室和现场工具可能会报告不同的值（即使是对于完全相同的网页），您需要了解实验室数据和现场数据之间的区别。
实验室数据
实验室数据是通过在具有预定义网络和设备条件的受控环境中加载网页来确定的。这些条件被称为实验室环境，有时也称为合成环境。
报告实验室数据的 Chrome 工具通常运行 Lighthouse。
实验室测试的目的是尽可能控制更多的因素，以便结果在每次运行时（尽可能地）保持一致且可重现。
现场数据
现场数据是通过监控所有访问页面的用户，并衡量每个用户个人体验的一组给定的性能指标来确定的。由于现场数据基于真实用户的访问，因此它反映了用户的实际设备、网络条件和地理位置。
现场数据也通常被称为 真实用户监控 (RUM) 数据；这两个术语可以互换使用。
报告现场数据的 Chrome 工具通常从 Chrome 用户体验报告 (CrUX) 中获取数据。网站所有者自行收集现场数据也很常见（且被推荐），因为它比仅使用 CrUX 能够提供更具可操作性的见解。
关于现场数据，最重要的是要理解它不仅仅是一个数字，而是一组数字的分布。也就是说，对于某些访问您网站的人来说，加载速度可能非常快，而对于另一些人来说，加载速度可能非常慢。您网站的现场数据是从您的用户那里收集的所有性能数据的完整集合。
例如，CrUX 报告显示了来自真实 Chrome 用户在 28 天期间的性能指标分布。如果您查看几乎任何 CrUX 报告，您都可以看到，一些访问网站的用户可能拥有非常好的体验，而另一些用户可能拥有非常糟糕的体验。
如果某个工具确实报告了给定指标的单个数字，那么它通常代表分布中的特定点。报告 Core Web Vitals 现场分数的工具使用第 75 百分位数。
查看上面屏幕截图中的现场数据中的 LCP，您可以看到一个分布，其中
- 88% 的访问的 LCP 为 2.5 秒或更短（良好）。
- 8% 的访问的 LCP 在 2.5 到 4 秒之间（需要改进）。
- 4% 的访问的 LCP 大于 4 秒（差）。
在第 75 百分位数，LCP 为 1.8 秒
来自同一页面的实验室数据显示 LCP 值为 3.0 秒。虽然此值大于现场数据中显示的 1.8 秒，但对于此页面来说，它仍然是一个有效的 LCP 值——它是构成完整加载体验分布的众多值之一。
实验室数据和现场数据为何不同
正如以上部分解释的那样，实验室数据和现场数据实际上衡量的是非常不同的事物。
现场数据包括各种各样的网络和设备条件，以及无数种不同类型的用户行为。它还包括任何其他影响用户体验的因素，例如浏览器优化（如后退/前进缓存 (bfcache)）或平台优化（如 AMP 缓存）。
相比之下，实验室数据有意限制了所涉及变量的数量。实验室测试包括：
- 单个设备……
- 连接到单个网络……
- 从单个地理位置运行。
任何给定实验室测试的具体细节可能无法准确代表给定页面或网站的现场数据的第 75 百分位数。
实验室的受控环境在调试问题或在部署到生产环境之前测试功能时很有用，但是当您控制这些因素时，您明确地没有表示在现实世界中跨所有类型的网络、设备功能或地理位置看到的差异。您通常也没有捕获真实用户行为（例如滚动、选择文本或点击页面上的元素）对性能的影响。
除了实验室条件与大多数真实世界用户的条件之间可能存在的脱节之外，还有许多更细微的差异也很重要，需要理解这些差异，以便充分理解您的实验室数据和现场数据，以及您可能发现的任何差异。
接下来的几节将详细介绍 Core Web Vitals 指标中实验室数据和现场数据之间可能存在差异的最常见原因
LCP
不同的 LCP 元素
在实验室测试中识别的 LCP 元素可能与用户在访问您的页面时看到的 LCP 元素不同。
如果您为给定的页面运行 Lighthouse 报告，它每次都会返回相同的 LCP 元素。但是，如果您查看同一页面的现场数据，您通常会发现各种不同的 LCP 元素，这取决于每次页面访问的许多具体情况。
例如，以下因素都可能导致同一页面确定不同的 LCP 元素：
- 不同的设备屏幕尺寸会导致视口中可见的元素不同。
- 如果用户已登录，或者以某种方式显示个性化内容，则不同用户的 LCP 元素可能会大相径庭。
- 与上一点类似，如果页面上正在运行 A/B 测试，则可能会导致显示非常不同的元素。
- 用户系统上安装的字体集会影响页面上文本的大小（从而影响哪个元素是 LCP 元素）。
- 实验室测试通常在页面的“基本” URL 上运行，而不会添加任何查询参数或哈希片段。但在现实世界中，用户经常共享包含片段标识符或文本片段的 URL，因此 LCP 元素实际上可能来自页面的中间或底部（而不是“首屏”）。
由于现场的 LCP 是根据页面所有用户访问的第 75 百分位数计算的，因此如果很大一部分用户拥有加载速度非常快的 LCP 元素（例如，使用系统字体渲染的文本段落），那么即使其中一些用户有一个大的、加载缓慢的图像作为其 LCP 元素，如果这种情况发生在少于 25% 的访问者身上，也可能不会影响该页面的分数。
或者，情况可能恰恰相反。实验室测试可能会将文本块识别为 LCP 元素，因为它正在模拟 Moto G4 手机，该手机的视口相对较小，并且您页面的主图最初在屏幕外渲染。但是，您的现场数据可能主要包括使用较大屏幕的 Pixel XL 用户，因此对于他们来说，加载缓慢的主图是他们的 LCP 元素。
缓存状态对 LCP 的影响
实验室测试通常使用冷缓存加载页面，但当真实用户访问该页面时，他们可能已经缓存了该页面的一些资源。
用户首次加载页面时，加载速度可能会很慢，但如果页面配置了适当的缓存，则用户下次返回该页面时可能会立即加载。
虽然某些实验室工具确实支持多次运行同一页面（以模拟返回访问者的体验），但实验室工具无法知道真实世界中新用户与返回用户的访问百分比。
具有良好优化的缓存配置和大量回头客的网站可能会发现，他们的真实世界 LCP 比他们的实验室数据指示的要快得多。
AMP 或签名交换优化
使用 AMP 构建或使用 签名交换 (SXG) 的网站可以由 Google 搜索等内容聚合器预加载。这可以为从这些平台访问您页面的用户带来显着更好的加载性能。
除了跨域预加载之外，网站本身还可以为网站上的后续页面预加载内容，这也可以提高这些页面的 LCP。
实验室工具不模拟从这些优化中看到的收益，即使它们模拟了，它们也无法知道您的流量中有多少百分比来自 Google 搜索等平台，而不是其他来源。
bfcache 对 LCP 的影响
当页面从 bfcache 恢复时，加载体验几乎是瞬间的，并且这些体验包含在您的现场数据中。
实验室测试不考虑 bfcache，因此如果您的页面是bfcache 友好型，则可能会导致现场报告的 LCP 分数更快。
用户交互对 LCP 的影响
LCP 识别视口中最大图像或文本块的渲染时间，但随着页面加载或新内容动态添加到视口，该最大元素可能会发生变化。
在实验室中，浏览器将等待页面完全加载完毕，然后再确定 LCP 元素是什么。但在现场，浏览器会在用户滚动或与页面交互后停止监控更大的元素。
这很有道理（而且是必要的），因为用户通常会等到页面“看起来”已加载后才会与之交互，而这正是 LCP 指标旨在检测的内容。考虑在用户交互后添加到视口的元素也没有意义，因为这些元素可能只是因为用户所做的某些事情才加载的。
不过，这方面的含义是，页面的现场数据可能会报告更快的 LCP 时间，具体取决于用户在该页面上的行为方式。
INP
INP 需要真实用户交互
INP 指标衡量页面对用户交互的响应速度，在用户实际选择与之交互时。
这句话的第二部分至关重要，因为实验室测试，即使是那些支持脚本用户行为的测试，也无法准确预测用户何时会选择与页面交互，因此无法准确衡量 FID。
TBT 不考虑用户行为
总阻塞时间 (TBT) 实验室指标旨在帮助诊断 INP 的问题，因为它量化了主线程在页面加载期间被阻塞的程度。
其想法是，具有大量同步 JavaScript 或其他密集渲染任务的页面在用户首次交互时更有可能阻塞主线程。但是，如果用户等到 JavaScript 执行完毕后再与页面交互，则 INP 可能会非常低。
用户何时选择与页面交互在很大程度上取决于页面看起来是否具有交互性，而这无法通过 TBT 衡量。
TBT 不考虑点击延迟
如果网站未针对移动设备查看进行优化，浏览器将在任何点击后添加 300 毫秒的延迟，然后再运行事件处理程序。他们这样做是因为他们需要确定用户是否尝试双击缩放，然后才能触发鼠标或点击事件。
此延迟计入页面的 INP，因为它会导致用户体验到的真实输入延迟。但由于此延迟在技术上不是长任务，因此它不会影响页面的 TBT。这意味着即使页面的 TBT 分数非常好，INP 也可能很差。
缓存状态和 bfcache 对 INP 的影响
正如适当的缓存可以改善现场的 LCP 一样，它也可以改善 INP。
在现实世界中，用户可能已经在其缓存中拥有了网站的 JavaScript，因此处理它可能花费更少的时间并导致更小的延迟。
从 bfcache 恢复的页面也是如此。在这些情况下，JavaScript 是从内存中恢复的，因此可能几乎没有或根本没有处理时间。
CLS
用户交互对 CLS 的影响
在实验室中测量的 CLS 仅考虑发生在首屏和加载期间的布局偏移，但这只是 CLS 实际测量内容的一个子集。
在现场，CLS 考虑页面整个生命周期中发生的所有意外布局偏移，包括用户滚动时或响应用户交互后缓慢的网络请求而发生偏移的内容。
例如，页面延迟加载没有尺寸的图像或 iframe 非常常见，当用户滚动到页面的这些部分时，这可能会导致布局偏移。但是，这些偏移可能仅在用户向下滚动时才会发生，而这通常不会在实验室测试中被捕获。
个性化内容
个性化内容（包括定向广告和 A/B 测试）会影响页面上加载的元素。它还会影响它们的加载方式，因为个性化内容通常在稍后加载并插入到页面的主要内容中，从而导致布局偏移。
在实验室中，页面通常在没有个性化内容的情况下加载，或者在为通用“测试用户”提供内容的情况下加载，这可能会或可能不会触发真实用户看到的偏移。
由于现场数据包括所有用户的体验，因此任何给定页面上发生的布局偏移量（和程度）都非常依赖于加载的内容。
缓存状态和 bfcache 对 CLS 的影响
加载期间布局偏移的两个最常见原因是加载缓慢的 Web 字体以及没有尺寸的图像和 iframe（如上所述），并且这两个问题都更有可能影响用户首次访问网站时的体验，即当他们的缓存为空时。
如果页面的资源被缓存，或者页面本身是从 bfcache 恢复的，则浏览器通常可以立即渲染图像和字体，而无需等待它们下载。这可能会导致现场的 CLS 值低于实验室工具可能报告的值。
当结果不同时该怎么办
作为一般规则，如果您有给定页面的现场数据和实验室数据，则应使用现场数据来确定工作的优先级。由于现场数据代表了真实用户正在体验的内容，因此它是真正了解您的用户在哪些方面遇到困难以及需要改进哪些方面的最准确方法。
另一方面，如果您的现场数据显示整体得分良好，但您的实验室数据表明仍有改进空间，那么值得了解可以进行哪些进一步的优化。
此外，虽然现场数据确实捕获了真实用户的体验，但它仅针对成功加载您网站的用户。实验室数据有时可以帮助识别扩大您网站覆盖范围的机会，并使其更易于网络较慢或低端设备的用户访问。
总的来说，实验室数据和现场数据都是有效性能衡量的重要组成部分。它们都有其优点和局限性，如果您只使用其中一种，您可能会错过改善用户体验的机会。