问题描述
谁知道是 Core web Vitals 详细信息，请帮我解决一些问题。
- 来源摘要与实验室数据有何不同？
- Speed Insight 如何获取来源摘要。这是同一页面或类似页面过去 28 天的总评分吗？
- 我检查了所有具有相同 LCP 的网站类别页面，并且在搜索控制台中它们位于一个部分内。理解所有这些页面如何具有相同的来源摘要但实验室数据不同，这让我有点困惑。
我附上了一张截图，让你看看是什么让我感到困惑。在实验室数据中看到 LCP 是 6.6s，Origin Summary 是 3.6s。它是如何工作的？？？？？？？
解决方法
起源总结
显示的时间数/值是该域跨多个页面的所有可用现实世界数据的平均值。
这是具有足够数据的网页的 28 天滚动平均值。
条形图显示汇总数据，因此您可以查看每个类别有多少访问者（红色 = 差，橙色 = 好，绿色 = 好）。
由于这是 Chrome User Experience (CrUX) 数据集中所有数据的平均值，因此您可以看到平均值较低，但仍有一个页面表现不佳/某个屏幕尺寸表现不佳（这就是为什么它们包括作为综合测试的聚合条仅在一种桌面和一种移动分辨率下，或者您可能只测试主页而其他页面表现不佳）。
评分：这与您的分数无关，仅供参考/帮助您识别综合测试可能无法解决的问题。
现场数据
如果正在测试的页面有更多流量，您可能会得到真实世界数据的页面细分（这将显示为“现场数据”）。您还没有足够的流量，这就是为什么您只能获得来源摘要。
与原始数据聚合和平均的方式相同，如果页面在 CrUX 数据集中有足够的数据，您将看到仅该页面的平均时间/值。这是对原始摘要数据的补充。
评分：这与您的分数无关，仅供参考/帮助您识别综合测试可能无法解决的问题。
实验室数据
这是来自您刚刚运行的综合测试的数据。这就是您的分数的来源。
来源摘要和现场数据与您在此处看到的分数完全没有关系，它们仅供参考。
分数和后续动作点是基于此测试运行“即时”生成的。
评分：您在运行审核时看到的分数是根据运行时收集的数据计算得出的。此计算中不使用原始数据或现场数据。
示例
在示例中，您给出的 LCP 实验室数据（合成）为 6.6 秒，原始数据（真实世界）为 3.6 秒。
要了解情况如何，假设您在 CrUX 数据集中有一个页面，Google 为其提供了三个真实世界的 LCP 值。 2 秒、3.9 秒和 4.9 秒。
然后，Google 会为您提供该页面的总条数（2 秒 = 好，3.9 秒 = 需要改进，4.9 秒 = 差），其中 33% 的绿色（好）、33% 的橙色（需要改进）和 33% 的红色（差）基于LCP scoring.
这些将是您的来源摘要条。
为您的起源摘要时间显示的时间将为 3.6 秒 - CrUX 数据集中这三个值的平均值 (((2 + 3.9 + 4.9) / 3) = 3.6。
至于 6.6 秒的实验室数据，测试已加载带有 throttling applied to represent a 4G connection on a mid-tier mobile phone 的页面。然后使用它收集的性能数据来计算 LCP 时间。
如果您改进页面并重新运行报告，LCP 时间可能会立即下降，因为它基于每次运行，而您的原始摘要数据需要 28 天才能完全更改以反映更改。
>因此，如果我的数据不在 CrUX 数据集中，我如何识别性能不佳的页面。
假设您有一个页面在 Lighthouse 综合测试中表现良好，但在某些屏幕尺寸的现实世界中表现不佳。
我们还假设没有足够的数据来显示该页面的字段数据。
如何找到破坏来源摘要的页面？
为此，您需要收集真实用户指标 (RUM) 数据。
RUM 数据是在真实用户使用您的网站时在现实世界中收集并存储在您的服务器上以供日后分析/问题识别的数据。
使用 Web Vitals Library 有一种简单的方法可以自行完成此操作。
这允许您收集 CLS、FID、LCP、FCP 和 TTFB 数据，这些数据足以识别性能不佳的页面.
您可以将收集到的数据通过管道传送至 your own API 或 Google Analytics 进行分析。
当 CrUX 数据集中没有任何/足够的数据供您分析时，这是收集特定页面数据的最佳方式。
,来源摘要是您网站上所有页面的汇总体验，而实验室数据特定于您在字段中输入的页面。
- 这意味着源摘要中的 LCP 是您网站上所有页面的聚合 LCP。 示例：假设您的网站上有 3 个页面，每个页面上的 LCP 分别为 2、5 和 7。这意味着您网站的平均 LCP 为 4.6 秒。现在，这使得具有更高 LCP 成为可能：在这种情况下为 7。
- 有关如何计算 LCP，请参阅上面提到的示例。它是过去 28 天内您在某个域名上发布的所有网页的综合评分。
- 您是否只检查相似的页面？