了解监控 Core Web Vitals 指标的工具可能会报告不同的数字，以及如何解读这些差异。
Google 提供了多种工具来帮助网站所有者监控其核心网页指标得分。这些工具分为两大类：
- 报告实验室数据（即在受控环境中使用预定义的设备和网络设置收集的数据）的工具。
- 报告实测数据的工具，即从访问您网站的真实用户那里收集的数据。
问题在于，有时实验室工具报告的数据可能与现场工具报告的数据有很大不同！您的实验室数据可能表明您的网站性能非常好，但实测数据表明它需要改进。或者，您的实测数据可能显示您的所有网页均正确无误，但实验室数据报告的得分可能非常低。
下面是来自 web.dev 的 PageSpeed Insights 报告的以下真实示例：在某些情况下，实验室数据和实地数据可能因所有核心网页指标指标而异：
工具之间的差异会让开发者感到困惑，这一点是可以理解的。这篇博文将介绍可能存在这些差异的主要原因（通过具体示例介绍各个 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 元素）。
- 实验室测试通常在网页的“基本”网址上运行，无需添加任何查询参数或哈希代码段。但在现实世界中，用户经常会共享包含片段标识符或文本片段的网址，因此 LCP 元素实际上可能位于网页的中间或底部，而不是“首屏”。
由于字段中的 LCP 是按网页所有用户访问的第 75 个百分位计算得出的，因此如果其中很大一部分用户的 LCP 元素加载速度非常快（例如使用系统字体呈现的一段文本），那么即使其中一些用户使用的是加载速度缓慢的大型图片作为其 LCP 元素，但如果该网页的访问者得分低于 25%，也不会影响该元素的得分。
反之亦然。实验室测试可能会将一段文本标识为 LCP 元素，因为它模拟的是视口相对较小的 Moto G4 手机，并且网页的主打图片最初是在屏幕之外呈现的。不过，您的实测数据可能主要包括屏幕较大的 Pixel XL 用户，因此对于他们而言，加载缓慢的主打图片是其 LCP 元素。
缓存状态对 LCP 的影响
实验室测试通常会加载具有冷缓存的页面，但当真实用户访问该页面时，他们可能已缓存了一些资源。
用户首次加载页面时，加载速度可能很慢，但如果页面配置了适当的缓存，则用户下次返回页面时，页面可能会立即加载。
虽然一些实验室工具确实支持多次运行同一网页（以模拟回访者的体验），但实验室工具无法得知来自新用户和回访用户的真实访问所占百分比。
具有经过充分优化的缓存配置且大量回访者的网站可能会发现其实际 LCP 比实验室数据显示的速度快得多。
AMP 或 Signed Exchange 优化
采用 AMP 构建或使用 Signed Exchange (SXG) 的网站可由 Google 搜索等内容聚合网站预加载。对于从这些平台访问您的网页的用户，这样可以显著提高加载性能。
除了跨源预加载之外，网站本身也可以为网站上的后续网页预加载内容，这也可以改善这些网页的 LCP。
实验工具不会模拟这些优化带来的成效，即使这样，它们也无法预测与其他来源相比，来自 Google 搜索等平台的流量所占的百分比。
bfcache 对 LCP 的影响
从 bfcache 恢复页面时，加载体验几乎是即时的，并且这些体验会包含在您的字段数据中。
实验室测试不考虑 bfcache，因此如果您的页面对 bfcache 友好，则可能会导致字段中报告的 LCP 得分更快。
用户互动对 LCP 的影响
LCP 可识别视口中最大图片或文本块的呈现时间，但该最大元素可能会随着网页加载或将新内容动态添加到视口而发生变化。
在本实验中，浏览器会等到页面完全加载后再确定 LCP 元素是什么。但在该字段中，当用户滚动页面或与页面互动后，浏览器将停止监控较大的元素。
这是合理的（并且是必要的），因为用户通常会等到页面“显示”加载后再与页面互动，而这正是 LCP 指标旨在检测的问题。此外，考虑在用户进行互动后添加到视口中的元素也毫无意义，因为这些元素可能是因用户某些操作而加载的。
但这意味着，网页的字段数据报告的 LCP 时间可能会更短，具体取决于用户在该网页上的行为。
FID
FID 需要实际用户互动
FID 指标用于衡量在用户实际选择与网页互动时网页对用户互动的响应速度。
这句话的第二部分至关重要，因为实验室测试（即使是支持脚本用户行为的测试）也无法准确预测用户何时选择与网页互动，因此无法准确衡量 FID。
TBT 不考虑用户行为
总阻塞时间 (TBT) 实验室指标旨在帮助您诊断 FID 问题，因为它可以量化主线程在页面加载期间被阻塞的情况。
其思路是，包含大量同步 JavaScript 或其他密集型渲染任务的页面更有可能在用户首次互动时出现阻塞的主线程。但是，如果用户等到 JavaScript 执行完毕后才与页面交互，则 FID 可能会非常低。
用户何时选择与页面互动在很大程度上取决于页面是否具有交互性，这一点无法通过 TBT 衡量。
TBT 不考虑点按延迟
如果网站未针对移动设备浏览进行优化，则浏览器会在每次点按后增加 300 毫秒的延迟，然后再运行事件处理脚本。这样做的原因是，它们需要确定用户是否在尝试点按两次进行缩放，然后才能触发鼠标或点击事件。
此延迟会计入页面的 FID，因为它会影响用户体验的实际输入延迟。但是，由于此延迟从技术上来讲并非长任务，因此不会影响页面的 TBT。这意味着，即使某个网页的 TBT 分数非常高，它也可能会有不佳的 FID。
缓存状态和 bfcache 对 FID 的影响
正确的缓存可以改善现场的 LCP，同样，它也可以改进 FID。
在现实世界中，用户的缓存中可能已经包含网站的 JavaScript，因此进行处理可以缩短时间并减少延迟。
对于从 bfcache 恢复的网页，也是如此。在这些情况下，JavaScript 会从内存中恢复，因此处理时间可能很短，甚至根本没有处理时间。
CLS
用户互动对 CLS 的影响
在实验中测量的 CLS 仅考虑在首屏和加载期间发生的布局偏移，但这只是 CLS 实际衡量结果的一部分。
在该字段中，CLS 会考虑网页整个生命周期内发生的所有意外布局偏移，包括在用户滚动时发生变化的内容，或因响应用户互动后缓慢的网络请求而发生变化的内容。
例如，网页会延迟加载未指定尺寸的图片或 iframe，这在用户滚动到网页的这些部分时可能会导致布局发生变化。但只有用户向下滚动才会发生这些变化，实验室测试通常不会捕获到。
个性化内容
个性化内容（包括有针对性的广告和 A/B 测试）会影响网页上加载哪些元素。此外，它还会影响加载方式，因为个性化内容往往会在稍后加载并插入页面的主要内容中，从而导致布局发生变化。
在实验室中，加载的网页通常要么没有个性化内容，要么包含一般性“测试用户”的内容，而这不一定会触发真实的用户看到的偏移。
由于现场数据包括所有用户的体验，因此在任何给定页面上经历的布局偏移的程度（和程度）在很大程度上取决于加载的内容。
缓存状态和 bfcache 对 CLS 的影响
加载期间布局偏移的两个最常见原因是没有尺寸的图片和 iframe（如上所述）和网页字体加载速度缓慢，这两个问题更有可能在用户首次访问某个网站时（其缓存为空）时影响体验。
如果网页的资源已缓存，或者网页本身已从 bfcache 中恢复，浏览器通常可以立即渲染图片和字体，而无需等待下载。这可能会导致该字段中的 CLS 值低于实验室工具可能报告的 CLS 值。
结果不一致时该怎么做
一般来说，如果给定网页的实地数据和实验室数据都包括在内，那么您应根据实测数据来确定各项工作的优先级。由于现场数据代表真实用户的体验，因此它是真正了解用户面临的问题以及需要改进的最准确方式。
另一方面，如果实测数据总体上成绩不错，但实验室数据表明仍有改进的空间，则有必要了解可以进行哪些进一步的优化。
此外，虽然实测数据确实可以捕获真实用户体验，但只能捕获能够成功加载您网站的用户。有时，实验室数据可以帮助您找到扩大网站覆盖面的机会，让网络速度较慢或设备较低者能够更轻松地访问网站。
总体而言，实验室数据和实地数据都是有效衡量性能的重要组成部分。这两种方式各有优势，各自有局限性，如果您只使用其中一种，可能会错失改善用户体验的机会。