了解监控核心 Web 指标的工具可能会报告不同的数字的原因，以及如何解读这些差异。
Google 提供了多种工具，可帮助网站所有者监控其核心 Web 指标得分。这些工具分为两大类：
- 报告实验室数据的工具：在具有预定义设备和网络设置的受控环境中收集的数据。
- 报告现场数据的工具 - 从访问您网站的真实用户收集的数据。
问题在于，实验室工具报告的数据有时可能与现场工具报告的数据大不相同！实验室数据可能表明您的网站效果出色，但现场数据却表明它需要改进。或者，现场数据可能显示您的所有网页都很好，但实验室数据可能报告得分非常低。
以下来自 web.dev 的 PageSpeed Insights 报告真实示例表明，在某些情况下，所有核心网页指标的实验室数据和实测数据可能会有所不同：
工具之间的差异是开发者感到困惑的一个可以理解的原因。本文介绍了出现这些差异的主要原因（并提供了涵盖每项 Core Web Vitals 指标的具体示例），以及在发现网页存在差异时应采取的措施。
实验室数据与现场数据
为了了解实验室工具和现场工具报告的值（即使是针对完全相同的网页）为何可能不同，您需要了解实验室数据和现场数据之间的差异。
实验室数据
实验室数据是通过在具有一组预定义网络和设备条件的受控环境中加载网页来确定的。这些条件称为实验环境，有时也称为合成环境。
报告实验室数据的 Chrome 工具通常会运行 Lighthouse。
实验室测试的目的是尽可能控制尽可能多的因素，以便每次运行测试时，结果尽可能一致且可重现。
现场数据
实测数据是通过监控访问网页的所有用户，并衡量每位用户的个别体验的一组给定性能指标而确定的。由于现场数据基于真实用户的访问，因此反映了用户的实际设备、网络状况和地理位置。
实测数据也常称为 Real User Monitoring (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 元素加载速度非常快（例如，使用系统字体呈现的段落文本），那么即使其中有少于 25% 的访问者的 LCP 元素是加载缓慢的大型图片，也可能不会影响该网页的得分。
反之亦然。实验室测试可能会将一块文本识别为 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 时间，具体取决于用户在该网页上的行为。
INP
INP 需要真实用户互动
INP 指标衡量的是在用户实际选择与网页互动时，网页对用户互动的响应速度。
该句话的第二部分至关重要，因为实验室测试（即使是支持脚本用户行为的测试）也无法准确预测用户何时会选择与网页互动，因此无法准确衡量 FID。
TBT 不考虑用户行为
Total Blocking Time (TBT) 实验室指标旨在帮助诊断 INP 问题，因为它可以量化主线程在网页加载期间被阻塞的时长。
其基本思想是，包含大量同步 JavaScript 或其他密集渲染任务的网页在用户首次互动时更有可能出现阻塞的主线程。不过，如果用户等到 JavaScript 执行完毕后再与网页互动，INP 可能非常低。
用户何时选择与网页互动在很大程度上取决于网页是否看起来具有互动性，而这无法通过 TBT 衡量。
TBT 不考虑点按延迟
如果网站未针对移动设备进行优化，浏览器会在任何点按操作后添加 300 毫秒的延迟，然后再运行事件处理脚本。之所以这样做，是因为它们需要先确定用户是否尝试双击以进行缩放，然后才能触发鼠标或点击事件。
此延迟会计入网页的 INP，因为它会增加用户实际体验到的输入延迟时间。但由于此延迟在技术上不是长任务，因此不会影响网页的 TBT。这意味着，网页即使具有非常出色的 TBT 得分，也可能具有较差的 INP。
缓存状态和 bfcache 对 INP 的影响
适当的缓存可以提高现场 LCP，同样也可以提高 INP。
在现实世界中，用户的缓存中可能已经包含某个网站的 JavaScript，因此处理该 JavaScript 可能需要更短的时间，延迟时间也会更短。
从 bfcache 恢复的网页也是如此。在这些情况下，JavaScript 会从内存中恢复，因此处理时间可能很短或根本没有。
CLS
用户互动对 CLS 的影响
在实验室中测量的 CLS 仅考虑折叠线上方和加载期间发生的布局偏移，但这只是 CLS 实际衡量的一部分。
在实践中，CLS 会考虑网页生命周期内发生的所有意外布局偏移，包括在用户滚动或在用户互动后响应网络请求缓慢时发生的内容偏移。
例如，网页延迟加载没有尺寸的图片或 iframe 是很常见的，这可能会导致用户滚动到网页的这些部分时布局发生偏移。不过，这些偏移可能只会在用户向下滚动时发生，而实验室测试通常不会捕获到这种情况。
个性化内容
个性化内容（包括定位广告和 A/B 测试）会影响网页上加载的元素。这还会影响内容的加载方式，因为个性化内容通常会在后面加载并插入到网页的主要内容中，从而导致布局偏移。
在实验室中，加载的网页通常不包含个性化内容，或者包含面向通用“测试用户”的内容，这可能或可能不会触发真实用户看到的变化。
由于现场数据包含所有用户的体验，因此任何给定网页上出现的布局偏移量（和程度）在很大程度上取决于所加载的内容。
缓存状态和 bfcache 对 CLS 的影响
导致加载期间出现布局偏移的两个最常见原因是没有尺寸的图片和 iframe（如上所述），以及加载缓慢的 Web 字体。这两个问题都更有可能影响用户首次访问网站时（缓存为空）的体验。
如果网页的资源已缓存，或者网页本身是从 bfcache 恢复的，浏览器通常可以立即呈现图片和字体，而无需等待下载。这可能会导致现场 CLS 值低于实验室工具报告的值。
结果不一致时该怎么办
一般来说，如果您有给定网页的现场数据和实验室数据，则应根据现场数据确定优先事项。由于实测数据代表了真实用户的体验，因此是最准确的方式，可真正了解用户遇到的问题以及需要改进的地方。
反之，如果您的现场数据显示各项得分都很高，但实验室数据表明仍有改进空间，那么您不妨了解可以进行哪些进一步优化。
此外，虽然实测数据确实可以捕获真实用户的体验，但仅适用于能够成功加载您网站的用户。实验室数据有时有助于发现扩大网站覆盖面并让网络速度较慢或设备较低端的用户更容易访问网站的机会。
总体而言，实验室数据和现场数据都是有效衡量性能的重要组成部分。这两种方法各有优点和局限，如果您只使用其中一种方法，就可能会错失改善用户体验的机会。