Any One Who Knows are Core web Vitals 详情请帮我解答。
我附上了一个屏幕截图，让你看看是什么让我感到困惑。 Lab Data 中的 LCP 为 6.6s，Origin Summary 显示为 3.6s。它是如何工作的？？？？？？
【问题讨论】：
标签： performance optimization google-developers-console google-search-console pagespeed-insights
显示的计时数字/值是该域跨多个页面的所有可用真实世界数据的平均值。
这是具有足够数据的网页的滚动 28 天平均值。
条形图显示汇总数据，因此您可以查看每个类别有多少访问者（红色 = 差，橙色 = 好，绿色 = 好）。
由于这是Chrome User Experience (CrUX) 数据集中所有数据的平均值，因此您可以看到较低的平均值，但仍有一个页面表现不佳/某个屏幕尺寸表现不佳（这就是为什么它们包括聚合条，因为综合测试仅在一种桌面和一种移动分辨率下进行，或者您可能只测试主页而其他页面表现不佳）。
评分：这与您的分数无关，仅供参考/帮助您识别综合测试可能无法解决的问题。
如果正在测试的页面有更多流量，您可能会得到按页面细分的真实数据（这将显示为“字段数据”）。您还没有足够的流量，这就是为什么您只能获得来源摘要。
如果页面在 CrUX 数据集中有足够的数据，则与原始数据聚合和平均的方式相同，您将看到仅该页面的平均时间/价值。这是对原始摘要数据的补充。
评分：这与您的分数无关，仅供参考/帮助您识别综合测试可能无法解决的问题。
这是您刚刚运行的综合测试的数据。这就是你的分数的来源。
原产地摘要和现场数据与您在此处看到的分数完全没有关系，它们只是提供信息。
分数和后续行动点是基于此测试运行“动态”生成的。
评分：您在运行审核时看到的分数是根据在该运行中收集的数据计算得出的。此计算中不使用原始数据或字段数据。
在示例中，您在实验室数据（合成）中给出的 LCP 是 6.6 秒，而原始数据（真实世界）是 3.6 秒。
要了解为什么会出现这种情况，假设您有一个位于 CrUX 数据集中的页面，Google 为其提供了三个真实世界的 LCP 值。 2s、3.9s 和 4.9s。
然后，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 天才能完全更改以反映更改。
假设您有一个页面在 Lighthouse 综合测试中表现良好，但在某些屏幕尺寸下在现实世界中表现不佳。
我们还假设没有足够的数据来显示该页面的字段数据。
如何找到破坏您的来源摘要的页面？
为此，您需要收集真实用户指标 (RUM) 数据。
RUM 数据是在真实用户使用您的网站时在现实世界中收集并存储在您的服务器上以供日后分析/问题识别的数据。
使用Web Vitals Library 有一个简单的方法可以自己完成。
这使您可以收集 CLS、FID、LCP、FCP 和 TTFB 数据，这足以识别性能不佳的页面。
您可以将收集到的数据通过管道传输到your own API 或Google Analytics 进行分析。
当 CrUX 数据集中没有任何/足够的数据供您分析时，这是收集特定页面数据的最佳方式。
【讨论】：
来源摘要是您网站上所有页面的总体体验，而实验室数据特定于您在该字段中输入的页面。
【讨论】：