衡量核心网络生命力的深入指南谷歌已经宣布，从2021年5月开始_（编辑_：日期刚刚移到2021年6月），他们将开始考虑将

谷歌已经宣布，从2021年5月开始_（编辑_：日期刚刚移到2021年6月），他们将开始考虑将"页面体验 "作为搜索排名的一部分，由一套名为 "核心网络指标 "的指标来衡量。这个日期很快就会到来，我相信我们很多人都被要求确保我们的核心网络指标合格，但你怎么能知道你是否合格？

回答这个问题实际上比你想象的要困难得多，虽然现在很多工具都在揭示这些核心网络指标，但有许多重要的概念和微妙之处需要理解。即使是谷歌的工具，如PageSpeed Insights和谷歌搜索控制台的核心网络指标报告，似乎也给出了混乱的信息。

为什么会这样，你怎么能确定你的修复措施真的奏效了呢？你如何才能准确了解你的网站的核心网络生命力？在这篇文章中，我将试图解释一下这里发生了什么，并解释这些工具的一些细微差别和误解。

什么是核心网络指标？

核心网络指标是一组三个指标，旨在衡量网站的**"核心 "体验**，即用户感觉是快还是慢，从而提供一个良好的体验。

网页将需要在所有三个核心网络指标的绿色测量范围内，以获得任何排名提升的全部好处。在良好范围之外，两个网页的核心网络生命力指标的不同值可能会导致不同的页面体验排名。

1.最大的含水量(LCP)

这个指标可能是这些指标中最容易理解的--它衡量你在页面上画出最大项目的速度--这可能是用户感兴趣的内容。这可能是一个横幅图片，一段文字，或任何东西。它是页面上最大的内容元素，这一事实很好地说明了它是最重要的部分。LCP是相对较新的，我们曾经测量过类似的First Contentful Paint（FCP），但是LCP已经被看作是一个更好的指标，可以衡量访客可能想要看到的内容何时被绘制出来。

LCP应该是用来衡量加载性能的，是我们性能界过去使用的所有旧指标（即第一个字节的时间（TTFB）、DOM内容加载、开始渲染、速度指数）的一个很好的代理 - 但是从用户的体验出发。它并不包括那些指标所涵盖的所有信息，但却是一个更简单的、单一的指标，它试图对页面的加载情况做出一个很好的指示。

2.首次输入延迟(FID)

这第二个指标衡量的是用户与页面互动的时间，例如点击一个链接或按钮，以及浏览器处理该点击之间的时间。它是用来衡量一个页面的互动性的。如果所有的内容都被加载了，但是页面却没有反应，那么对用户来说就是一种令人沮丧的体验。

重要的一点是，这个指标是无法模拟的，因为它确实取决于用户何时真正点击或以其他方式与页面互动，然后需要多长时间才能采取行动。在使用没有任何直接用户互动的测试工具时，总阻塞时间（TBT）是FID的一个很好的代理，但在看FID时，也要注意互动时间（TTI）。

3.累积布局转移（CLS

一个_非常_有趣的指标，由于一些原因，它与之前的其他指标完全不同。它被设计用来衡量页面的视觉稳定性--基本上，当新的内容插入时，它有多大的跳动。我相信我们都曾点击过一篇文章，开始阅读，然后随着图片、广告和其他内容的加载，文字跳动。

这对用户来说是相当刺耳和恼人的，所以最好把它降到最低。更糟糕的是，当你要点击的那个按钮突然移动，而你却点击了另一个按钮CLS试图解释这些布局的变化。

实验室与RUM

要了解核心网络指标的一个关键点是，它们是基于现场指标或真实用户指标（RUM）。谷歌使用来自Chrome用户的匿名数据来反馈指标，并在Chrome用户体验报告（CrUX）中提供这些数据。这些数据就是他们用来衡量搜索排名的这三个指标的。CrUX数据可以在许多工具中使用，包括在您的网站的谷歌搜索控制台中。

使用RUM数据的事实是一个重要的区别，因为其中一些指标（FID除外）可以在合成或 "基于实验室 "的网络性能工具中获得，如Lighthouse，这些工具在过去一直是网络性能监测的主力。这些工具在模拟网络和设备上运行页面负载，然后告诉你该测试运行的指标是什么。

因此，如果你在你的高功率开发者机器上运行Lighthouse并得到很好的分数，这可能并不反映用户在现实世界中的体验，因此谷歌将使用什么来衡量你的网站用户体验。

LCP将非常依赖于网络条件和正在使用的设备的处理能力（而更多的用户可能使用的是比你想象中更低功率的设备！）。).然而，一个相反的观点是，至少对于许多西方国家的网站来说，我们的手机也许并不像Lighthouse等工具在移动模式下所显示的那样低功率，因为这些手机是相当节流的。因此，你可能会注意到你在手机上的现场数据比测试时显示的要好（有一些关于改变Lighthouse手机设置的讨论）。

同样，FID通常取决于处理器的速度，以及设备如何处理我们发送给它的所有内容--无论是需要处理的图片、需要在页面上布局的元素，当然还有我们喜欢发送到浏览器上的所有JavaScript。

理论上，CLS更容易在工具中测量，因为它不太容易受到网络和硬件变化的影响，所以你会认为它不像LAB和RUM之间的差异那样--除了一些重要的考虑因素，最初可能不明显。

它是在整个页面的生命周期中进行测量的，而不是像典型的工具那样只对页面的加载进行测量，我们将在本文后面更多的探讨这个问题。当实验室模拟的页面加载有很低的CLS，但现场的CLS分数却高得多，这就造成了很多混乱，因为CLS是由滚动或测试工具通常测量的初始加载后的其他变化引起的。
这可能取决于浏览器窗口的大小--通常像PageSpeed Insights这样的工具，测量移动和桌面，但不同的移动设备有不同的屏幕尺寸，而桌面往往比这些工具设定的大得多（Web Page Test最近增加了他们的默认屏幕尺寸，试图更准确地反映使用情况）。
不同的用户在网页上看到不同的东西。Cookie横幅、定制内容（如促销活动）、Adblockers、A/B测试，仅举几个可能不同的项目，都会影响绘制的内容，因此CLS用户可能会体验到什么。
它仍在不断发展，Chrome团队一直忙于修复 "看不见的 "转变和类似的不应该被计入CLS的内容。对CLS实际测量方式的更大改变也在进行中。这意味着你可以看到不同的CLS值，这取决于正在运行的Chrome浏览器的版本。

在基于实验室的测试工具中使用相同的指标名称，而这些指标可能无法准确反映现实生活中的版本，这令人困惑，有人建议我们应该在Lighthouse中重新命名这些指标的部分或全部，以区分这些模拟指标和现实世界中的RUM指标，这些指标为谷歌排名提供动力。

以前的网络性能指标

另一个困惑点是，这些指标是新的，与我们过去传统上用来衡量网络性能的指标不同，这些指标是由一些工具浮现出来的，比如PageSpeed Insights--一个免费的在线审计工具。只需输入你想要审计的URL，然后点击分析，几秒钟后你就会看到两个标签（一个是移动端，一个是桌面端），其中包含大量的信息。

最上方是Lighthouse的性能评分，满分100分。这在网络性能社区中已经是众所周知的了，并经常被引用为一个关键的性能指标，以达到目标，并将许多指标的复杂性总结为一个简单、易懂的数字。这与Core Web Vitals的目标有一些重叠，但它不是对三个Core Web Vitals（甚至是基于实验室的版本）的总结，而是对更多指标的总结。

目前，六项指标构成了Lighthouse的性能得分--包括一些核心网络指标和一些其他指标。

首要的内容绘画（FCP
速度指数(SI)
最大的网页内容(LCP)
互动时间(TTI)
总阻塞时间(TBT)
累积布局转移（CLS）。

更为复杂的是，这六项指标在性能评分中的权重各不相同，尽管CLS是核心网络指标之一，但目前只占Lighthouse性能评分的5%（我敢打赌，在CLS的下一次迭代发布后，这一比例会很快提高）。所有这些都意味着，你可以获得非常高的、绿色的Lighthouse性能得分，并认为你的网站很好，但仍然无法通过核心网站指标的门槛。因此，你现在可能需要调整你的工作重点，看看这三个核心指标。

越过那张截图中的绿色大分数，我们转到现场数据，我们得到了另一个混淆点。首先Contentful Paint和其他三个核心网络指标一起显示在这个领域的数据中，尽管它不是核心网络指标的一部分，而且，就像在这个例子中，我经常发现它被标记为警告，即使其他指标都通过了。(也许这种情况的阈值需要调整一下？)FCP是否以微弱的优势错过了成为核心网络生命力的机会，或者它只是在四个指标上看起来更平衡？这个领域数据部分很重要，我们稍后再来讨论这个问题。

如果被测试的特定URL没有字段数据，那么整个域名的起源数据将被显示出来（如上图所示，当该特定URL有字段数据时，这个数据默认是隐藏的）。

在字段数据之后，我们得到了实验室数据，我们看到了构成性能分数的六个指标在顶部。如果你点击右上方的切换按钮，你甚至可以得到更多关于这些指标的描述。

正如你所看到的，这里包括LCP和CLS的实验室版本，由于它们是Core Web Vitals的一部分，它们得到了一个蓝色的标签，以标记它们是特别重要的。PageSpeed Insights还包括一个有用的计算器链接，以查看这些分数对顶部的总分的影响，它允许你调整它们，以查看改善每个指标将对你的分数产生什么影响。但是，正如我所说的，当核心网络指标沐浴在目前所有关注的光芒中时，网络性能得分很可能会退居次席。

Lighthouse还对额外的_机会_和_诊断_进行了近50项其他检查。这些检查并不直接影响得分，也不影响核心网络指标，但网站开发人员可以利用它们来提高网站的性能。这些也会在PageSpeed Insights的所有指标下面浮现出来，所以只是在上面的截图中没有看到。把这些看作是关于如何提高性能的建议，而不是必须要解决的具体问题。

诊断程序将向你显示LCP元素和对你的CLS得分有贡献的转变，这是在优化你的核心网络生命力时非常有用的信息

因此，虽然过去网络性能的倡导者可能主要集中在Lighthouse分数和审计上，但我认为这是对三个核心网络生命力指标的归零--至少在接下来的一段时间里，当我们对它们有所了解时。其他Lighthouse指标和总分对于优化你的网站性能仍然是有用的，但核心网络生命力目前在新的网络性能和SEO博客文章中占据了大部分的篇幅。

查看您网站的核心网络指标

快速查看单个URL和整个网站的核心网络指标的最简单方法是将一个URL输入PageSpeed Insights，如上所述。然而，要查看谷歌如何看待你整个网站的核心网络生命力，请访问谷歌搜索控制台。这是一个由谷歌创建的免费产品，允许你了解谷歌如何 "看到 "你的整个网站，包括你的网站的核心网络指标（尽管这里的数据更新频率有一些--我们可以说--"令人沮丧"）。

谷歌搜索控制台长期以来一直被搜索引擎优化团队使用，但由于网站开发人员需要解决核心网络生命力的问题，开发团队如果还没有得到这个工具的访问权，也应该得到这个工具。要获得访问权，你将需要一个谷歌账户，然后通过各种手段（在你的网络服务器中放置一个文件，添加一个DNS记录......等）验证你对网站的所有权。

谷歌搜索控制台（Google Search Console）中的核心网络生命力报告给你一个总结，说明你的网站在过去90天内是如何满足核心网络生命力的。

理想情况下，要想被认为完全通过了核心网络指标，你希望你的所有网页都是绿色的，没有琥珀色或红色。虽然琥珀色是一个很好的指标，说明你已经接近通过，但实际上只有绿色才是最重要的，所以不要满足于第二好的。你是需要_所有的_页面都通过，还是只需要你的关键页面通过，这取决于你，但往往在许多页面上会有类似的问题，为网站解决这些问题可以帮助把不通过的URL数量带到一个更可控的水平，你可以做出这些决定。

最初，谷歌只打算将核心网络生命力排名应用于移动端，但这肯定只是时间问题，然后也会推广到桌面端，所以当你在那里审查和修复你的页面时，不要忽视桌面端。

点击其中一个报告会给你更多的细节，说明哪些网页的生命力没有得到满足，然后是受影响的URL的样本。谷歌搜索控制台将URL分组到桶中，从理论上讲，允许你一起处理类似的页面。然后，你可以点击一个URL，运行PageSpeed Insights，对特定的URL进行快速的性能审计（包括显示该页面的核心网络生命力领域数据，如果它们可用的话）。然后，你修复它所突出的问题，重新运行PageSpeed Insights以确认实验室指标现在是正确的，然后继续到下一个页面。

然而，一旦你开始看那份核心网络指标报告（对我们中的一些人来说是痴迷的！），你可能就会感到沮丧，因为这份报告似乎没有更新以反映你的努力工作。它似乎确实每天都在更新，因为图表在移动，然而，即使你发布了你的修复措施，它也经常几乎没有变化--为什么？

同样地，PageSpeed Insights领域的数据仍然顽固地显示该URL和网站是失败的。那么这里有什么故事呢？

Chrome用户体验报告（CrUX

Web Vitals更新缓慢的原因是，该领域的数据是基于Chrome用户体验报告（CrUX）中最近28天的数据，而其中只有该数据的第75百分位数。使用28天的数据和第75个百分点的数据是好事，因为它们消除了变异和极端情况，更准确地反映了你的网站的性能，而不会造成很多难以解释的噪音。

性能指标非常容易受到网络和设备的影响，所以我们需要抚平这些噪音，以了解你的网站对大多数用户来说是如何表现的真实情况。然而，这一点的反面是，它们的更新速度慢得令人沮丧，从纠正问题到你看到纠正的结果反映在那里，形成一个非常缓慢的反馈循环。

特别是第75个百分点（或p75）很有趣，它所产生的延迟，因为我认为这一点没有被很好地理解。它看的是在这28天内你的访客的页面浏览量中，每个核心网络指标的75%是什么指标。

因此，它是你75%的页面浏览量的最高核心网络生命力得分（或者反过来说，你75%的页面浏览量的最低核心网络生命力得分将少于）。因此，它_不是_这75%的页面浏览量的平均值，而是这组用户的最差值。

这就造成了报告的延迟，而非基于百分位数的滚动平均值则不会。我们必须在这里做一些数学计算（我会尽量减少），但是为了简单起见，我们假设每个人在上个月的LCP都是10秒，而你把它固定下来，现在只需要1秒，并且假设你每天都有完全相同数量的访问者，他们都得到这个LCP。

在这种过于简单的情况下，你会得到以下指标。

日	LCP	28天平均数	28天P75
第0天	10	10	10
第1天	1	9.68	10
第二天	1	9.36	10
第三天	1	9.04	10
...	...	...	...
第20天	1	3.57	10
第21天	1	3.25	10
第22天	1	2.93	1
第23天	1	2.61	1
...	...	...	...
第27天	1	1.32	1
第28天	1	1	1

因此，你可以看到你没有看到你的CrUX分数的大幅改善，直到第22天，它突然跳到新的、较低的值（一旦我们跨越28天平均值的75%--不是巧合！）。在那之前，你有超过25%的用户是基于改变之前收集的数据，因此我们得到的是旧值10，因此你的p75值停留在10。

因此，看起来你在很长一段时间内没有任何进展，而平均数（如果使用的话）会显示出立即开始逐渐下降的情况，因此实际上可以看到进展。从好的方面看，在过去的几天里，平均数实际上高于p75值，因为p75的定义是完全过滤掉极端值。

上表中的例子，虽然被大大简化了，但解释了为什么许多人可能会看到下面这样的Web Vitals图表，即有一天你的所有网页都跨越了一个阈值，然后就好了_（呜呼！_）。

这可能会让那些期望在你解决页面问题时有更多渐进（和即时）变化的人感到惊讶，因为有些页面的访问频率比其他页面高。与此相关的是，看到你的Search Console图表经历一个黄色时期也是很正常的，这取决于你的修复措施和它们对阈值的影响，然后才是甜蜜、甜蜜的绿色。

戴夫-斯马特（Dave Smart）做了一个引人入胜的实验，追踪搜索控制台报告中核心网络生命体数据的变化，他想看看更新图表的速度有多快。他没有考虑到CrUX的75分位数部分（这使得他的一些图表中缺乏运动更有意义），但仍然是一个关于这个图表如何更新的迷人的现实生活实验，非常值得一读

我自己的经验是，这种28天p75的方法并不能完全解释核心网络生命力报告的滞后性，我们稍后会讨论一些其他的潜在原因。

那么，这就是你能做的最好的事情，进行修复，然后耐心等待，敲击你的手指，直到CrUX认为你的修复是值得的，并更新Search Console和PageSpeed Insights中的图表？如果事实证明你的修复不够好，那就重新开始整个循环？在这个即时反馈满足我们渴望的时代，以及开发人员提高生产力的紧密反馈回路中，这一点都不令人满意

好吧，在此期间，你可以做一些事情，尝试看看任何修复是否会得到预期的效果。

更详细地深入研究核心数据

既然测量的核心是CrUX数据，让我们再深入研究一下，看看它还能告诉我们什么。回到PageSpeed Insights，我们可以看到它不仅浮现了网站的p75值，而且还浮现了下面色块中显示的绿色、黄色和红色桶中的页面浏览百分比。

上面的截图显示，CLS没有通过核心网络指标的评分，其p75值为0.11，高于0.1的合格限制。然而，尽管字体的颜色是红色，但这实际上是一个琥珀色的排名（因为红色将高于0.25）。更有趣的是，绿色条是在73%--一旦达到75%，这个页面就通过了核心网络指标。

虽然你不能看到CrUX的历史值，但你可以随着时间的推移进行监测。如果它明天上升到74%，那么我们的趋势是正确的（受波动影响！），并希望很快达到神奇的75%。对于距离较远的数值，你可以定期检查并看到增长，然后预测出你何时可能开始显示为合格。

CrUX也可以作为一个免费的API来获得这些百分比的更精确的数字。一旦你注册了一个API密钥，你可以用这样的curl命令调用它（根据情况替换API_KEY、formFactor和URL）。

curl -s --request POST 'https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=API_KEY' \
    --header 'Accept: application/json' \
    --header 'Content-Type: application/json' \
    --data '{"formFactor":"PHONE","url":"https://www.example.com"}'

然后你会得到一个JSON响应，像这样。

{
  "record": {
    "key": {
      "formFactor": "PHONE",
      "url": "https://www.example.com/"
    },
    "metrics": {
      "cumulative_layout_shift": {
        "histogram": [
          {
            "start": "0.00",
            "end": "0.10",
            "density": 0.99959769344240312
          },
          {
            "start": "0.10",
            "end": "0.25",
            "density": 0.00040230655759688886
          },
          {
            "start": "0.25"
          }
        ],
        "percentiles": {
          "p75": "0.00"
        }
      },
      "first_contentful_paint": {
        ...
      }
    }
  },
  "urlNormalizationDetails": {
    "originalUrl": "https://www.example.com",
    "normalizedUrl": "https://www.example.com/"
  }
}

顺便说一下，如果上面的内容让你有点害怕，你想用更快的方式来获得一个URL的数据，那么PageSpeed Insights也会返回这个精度，你可以通过打开DevTools，然后运行你的PageSpeed Insights测试，并找到它的XHR调用来查看。

还有一个交互式的CrUX API探索器，允许你对CrUX API进行样本查询。不过，对于常规的API调用，获得一个免费的密钥并使用Curl或其他一些API工具通常更容易。

API也可以用 "原点 "而不是URL来调用，这时它将给出所有访问该域的页面的汇总值。PageSpeed Insights暴露了这一信息，如果你的URL没有CrUX信息可用，这可能很有用，但Google Search Console没有。谷歌还没有说明（也不太可能说明！）核心网络指标究竟会如何影响排名。原点级别的分数会影响排名，还是只影响单个URL的分数？或者，像PageSpeed Insights一样，当单个URL数据不存在时，谷歌是否会回落到原始水平的分数？目前还很难知道，到目前为止，唯一的提示是FAQ中的这个。

问：如何计算最近发布的、尚未产生28天数据的URL的分数？

答：类似于Search Console报告页面体验数据的方式，我们可以采用一些技术，比如将相似的页面分组，并根据这种聚合计算分数。这适用于那些几乎没有流量的页面，所以没有现场数据的小网站不需要担心。

CrUX API可以以编程方式调用，谷歌CrUX团队的Rick Viscomi创建了一个谷歌表格监控器，允许你批量检查URL或来源，如果你想密切监控一些URL或来源，甚至可以自动跟踪CrUX数据的时间。只需克隆工作表，进入Tools → Script 编辑器，然后用你的密钥输入CRUX_API_KEY 的脚本属性（这需要在传统编辑器中完成），然后运行该脚本，它将为给定的URL或起源调用CrUX API，并在工作表的底部添加数据行。这样就可以定期运行或安排定期运行。

我用它来检查一个网站的所有URL，该网站在Google Search Console中的Core Web Vitals报告更新缓慢，它证实CrUX没有很多URL的数据，其余大部分已经通过，所以再次表明Google Search Console报告是落后的--即使从CrUX数据来看，它应该是基于的。我不确定这是否是由于之前失败的URL，但现在没有足够的流量来获得更新的CrUX数据显示它们通过，或者是由于其他原因，但这向我证明，这个报告肯定很慢。

我怀疑其中很大一部分是由于CrUX中没有数据的URL，而谷歌搜索正在尽力为它们代理一个值。因此，这份报告是一个很好的开始，可以了解你的网站的概况，也可以监测未来的发展，但不是一个很好的报告，可以解决你想要更多即时反馈的问题。

对于那些想更深入了解CrUX的人来说，BigQuery中提供了CrUX数据的月度表格（仅在原点级别，所以不是针对单个URL），Rick还记录了如何在此基础上创建CrUX仪表盘，这可能是监测你的网站在几个月内整体表现的一个好方法。

关于Crux数据的其他信息

因此，通过上述内容，你应该对CrUX数据集有一个很好的了解，为什么使用它的一些工具似乎更新缓慢且不稳定，以及如何更多地探索它。但是在我们继续讨论它的替代品之前，还有一些关于CrUX的事情需要了解，以帮助你真正理解它所显示的数据。因此，这里收集了我收集的关于CrUX与Core Web Vitals有关的其他有用信息。

CrUX仅适用于Chrome浏览器。所有这些iOS用户和其他浏览器（桌面Safari、Firefox、Edge......等），更不用说老式浏览器（IE浏览器--赶紧淡出吧！）的用户体验都没有反映在CrUX数据中，因此也没有反映在谷歌的Core Web Vitals视图中。

现在，Chrome浏览器的使用率非常高（尽管对你的网站访问者来说可能不是这样），而且在大多数情况下，它所强调的性能问题也会影响到其他浏览器，但这是需要注意的事情。至少可以这么说，谷歌在搜索领域的垄断地位，现在鼓励人们为他们的浏览器进行优化，这确实让人感觉有点 "恶心"。我们将在下面谈一谈这种有限观点的替代解决方案。

正在使用的Chrome浏览器的版本也会产生影响，因为这些指标（尤其是CLS）仍在不断发展，同时也在发现和修复错误。这为理解数据增加了另一层面的复杂性。在最近的Chrome版本中，CLS得到了持续的改进，Chrome 92可能会对CLS进行重新定义。同样，正在使用现场数据的事实意味着可能需要一些时间才能将这些变化反馈给用户，然后再反馈给CrUX数据。

CrUX只针对登录到Chrome的用户，或者引用实际定义。

"[CrUX是]从选择同步其浏览历史、未设置同步口令并启用了使用统计报告的用户中汇总而来。"

-Chrome用户体验报告，谷歌开发者

因此，如果你正在寻找一个主要从企业网络访问的网站的信息，而这些设置是由中央IT政策关闭的，那么你可能不会看到太多的数据--特别是如果那些可怜的企业用户仍然被迫使用IE浏览器的话!

CrUX包括所有的页面，包括那些通常不会出现在谷歌搜索中的页面，如"无索引/被抢注/登录的页面将被包括在内"（尽管在CrUX中暴露的URL和来源有最低门槛）。现在，这些类别的网页很可能不会被纳入谷歌搜索结果，因此对它们的排名影响可能并不重要，但它们仍然会被纳入CrUX中。然而，Google Search Console中的Core Web Vitals报告似乎只显示被索引的URL，所以它们不会出现在那里。

PageSpeed Insights和CrUX原始数据中显示的起源数字将包括那些非索引的、非公开的页面，正如我上面提到的，我们不确定这有什么影响。我工作的一个网站有很大比例的访问者访问我们的登录页面，虽然公共页面的性能非常好，但登录页面却不是，这严重歪曲了原生的Web Vitals得分。

CrUX API可以用来获取这些登录URL的数据，但PageSpeed Insights等工具却不能（因为它们运行的是实际的浏览器，所以会被重定向到登录页面）。一旦我们看到CrUX的数据并意识到其影响，我们就修复了这些数据，原点数据已经开始下降，但和以往一样，这需要时间来反馈。

未被索引或登录的页面通常也是 "应用程序"，而不是单独的页面集合，因此可能使用单页应用程序的方法，有一个真正的URL，但在其下有许多不同的页面。这可能会影响到CLS，特别是由于它是在页面的整个生命周期内测量的（尽管希望即将到来的对CLS的修改会帮助解决这个问题）。

如前所述，Google Search Console中的Core Web Vitals报告虽然基于CrUX，但绝对不是同样的数据。正如我前面所说，我怀疑这主要是由于Google Search Console试图为不存在CrUX数据的URL估计Web Vitals。这份报告中的样本URL也与CrUX的数据不一致。

我见过很多URL被修复的例子，PageSpeed Insights中的CrUX数据，或直接通过API显示它通过了Web Vitals，然而当你点击核心Web Vitals报告中的红线并获得样本URL时，这些通过的URL将被包括在内**，好像它们是失败**的。我不确定Google Search Console使用什么启发式方法来进行分组，或者它和样本URL的更新频率，但在我看来，它可以做得更频繁地更新

CrUX是基于页面浏览量的。这意味着你最受欢迎的页面将对你的起源CrUX数据有很大影响。一些页面每天都会在CrUX中进出，因为它们达到或不达到这些阈值，也许原点数据会对这些页面产生影响？另外，如果你在一段时间内有一个大的活动和大量的访问，然后进行了改进，但此后访问量减少，你会看到更大比例的旧的、更糟糕的数据。

CrUX数据分为移动、桌面和平板电脑--尽管在大多数工具中只有移动和桌面是公开的。如果你真的想看平板电脑的数据，CrUX API和BigQuery允许你看平板电脑的数据，但我建议集中在移动端，然后是桌面。另外，请注意在某些情况下（如CrUX API），它被标记为手机而不是移动，以反映它是基于外形因素的，而不是说数据是基于移动网络的。

总而言之，这些问题很多都是现场（RUM）数据收集的影响，但是当你被赋予 "修复我们的核心网络生命体征 "的任务时，所有这些细微的差别都是需要承担的。你越了解这些核心网络生命体征是如何收集和处理的，数据就越有意义，你就可以把更多的时间花在解决实际问题上，而不是抓耳挠腮地想为什么它没有报告你认为它应该报告的东西。

获得更快的反馈

好了，现在你应该已经很好地掌握了核心网络生命体征是如何通过各种工具收集和展示的，但这仍然留给我们一个问题，即我们如何才能获得更好、更快的反馈。等到21-28天后才看到CrUX数据的影响--才意识到你的修复措施是不够的--这太慢_了_。因此，虽然上面的一些提示可以用来查看CrUX是否朝着正确的方向发展，但它仍然不理想。因此，唯一的解决办法是在CrUX之外寻找，以便复制它正在做的事情，但要更快地暴露数据。

市场上有许多伟大的商业RUM产品，它们测量你的网站的用户性能，并在仪表板或API中公开数据，使你能够以比CrUX更多的深度和更细的频率查询数据。我不会在这里给出任何产品的名称，以避免被指责为偏袒，或得罪任何被我遗漏的人!由于Core Web Vitals是以浏览器API的形式公开的（至少是基于Chromium的浏览器，其他浏览器如Safari和Firefox还没有公开一些较新的指标，如LCP和CLS），理论上，它们应该是暴露在CrUX下的相同数据，因此也是暴露在Google下的相同数据--但要注意上述的注意事项

对于那些无法访问这些RUM产品的人来说，谷歌也提供了一个Web Vitals JavaScript库，它允许你访问这些指标，并按你认为合适的方式报告它们。通过在您的网页上运行以下脚本，可以将这些数据发回给Google Analytics。

<script type="module">
  import {getFCP, getLCP, getCLS, getTTFB, getFID} from 'https://unpkg.com/web-vitals?module';

  function sendWebVitals() {
    function sendWebVitalsGAEvents({name, delta, id, entries}) {
      if ("function" == typeof ga) {        ga('send', 'event', {
          eventCategory: 'Web Vitals',
          eventAction: name,
          // The id value will be unique to the current page load. When sending
          // multiple values from the same page (e.g. for CLS), Google Analytics can
          // compute a total by grouping on this ID (note: requires eventLabel to
          // be a dimension in your report).
          eventLabel: id,
          // Google Analytics metrics must be integers, so the value is rounded.
          // For CLS the value is first multiplied by 1000 for greater precision
          // (note: increase the multiplier for greater precision if needed).
          eventValue: Math.round(name === 'CLS' ? delta * 1000 : delta),
          // Use a non-interaction event to avoid affecting bounce rate.
          nonInteraction: true,
          // Use sendBeacon() if the browser supports it.
          transport: 'beacon'
        });
      }
    }

    // Register function to send Core Web Vitals and other metrics as they become available
    getFCP(sendWebVitalsGAEvents);
    getLCP(sendWebVitalsGAEvents);
    getCLS(sendWebVitalsGAEvents);
    getTTFB(sendWebVitalsGAEvents);
    getFID(sendWebVitalsGAEvents);

  }

  sendWebVitals();
</script>

或者，你也可以把它作为一个外部脚本。

<script type="module" src="/javascript/send-web-vitals.js"></script>

现在我意识到添加另一个脚本来测量你的网站的影响是一种讽刺，这可能部分是因为有太多的JavaScript，但正如你在上面看到的，这个脚本相当小，它加载的库只有进一步压缩的1.7 kB（未压缩的4.0 kB）。此外，作为一个模块（它将被那些不理解网络生命力的旧浏览器所忽略），它的执行是延迟的，所以不应该对你的网站产生太大的影响，而且它所收集的数据对于帮助你调查你的核心网络生命力是非常有价值的，比CrUX数据允许的方式更实时。

该脚本注册了一个**函数，**当每个指标可用时，发送一个Google Analytics事件。对于FCP和TTFB来说，这是在页面加载后立即进行的，对于FID来说，是在用户的第一次互动后进行的，而对于LCP和CLS来说，是在页面被导航离开或背景化时进行的，实际的LCP和CLS是肯定知道的。你可以使用开发者工具看到这些信标正在为该页面发送，而CrUX数据是在后台发生的，没有在这里暴露。

把这些数据放在像Google Analytics这样的工具中的好处是，你可以根据里面的所有其他信息对数据进行切分，包括形式因素（桌面或移动）、新访客或老访客、漏斗转化率、Chrome版本等等。而且，由于它是RUM数据，它将受到实际使用情况的影响--使用较快或较慢设备的用户将报告较快或较慢的数值--而不是由开发人员在他们的高规格机器上测试并说它很好。

同时，你需要记住，CrUX的数据是在28天内汇总的，只看第75个百分点的原因是为了消除差异性。获得原始数据可以让你看到更细化的数据，但这意味着你更容易受到极端变化的影响。尽管如此，只要你记住这一点，保持对数据的早期访问可能是非常有价值的。

谷歌的菲尔-沃尔顿创建了一个Web-Vitals仪表板，可以指向你的谷歌分析账户下载这些数据，计算第75个百分点（所以这有助于解决变化！），然后显示你的核心Web Vitals得分、信息柱状图、数据的时间序列，以及你的前5个访问页面，以及导致这些得分的最主要元素。

使用这个仪表板，你可以对单个页面进行过滤（使用ga:pagePath==/page/path/index.html 过滤器），并在你发布修复后的一天内看到这样一个非常令人满意的图表，并知道你的修复已经成功，你可以继续进行下一个挑战！。

用更多一点的JavaScript，你也可以把更多的信息（比如LCP元素是什么，或者哪个元素造成了最多的CLS）暴露在Google Analytics的自定义维度中。菲尔就此写了一篇优秀的Debug Web Vitals in the field帖子，基本上说明了如何增强上述脚本来发送这些调试信息，如这个版本的脚本所示。

这些维度也可以在仪表盘中报告（使用ga:dimension1 作为Debug dimension 字段，假设这是在脚本中的Google Analytics客户维度1中发送回来的），以获得像这样的数据，看到这些浏览器看到的LCP元素。

正如我之前所说的，商业的RUM产品通常也会披露这类数据（以及更多！），但对于那些刚刚涉足水面，还没有准备好为这些产品做出财务承诺的人来说，这至少提供了对基于RUM的指标的第一次尝试**，以及它们对于获得你正在实施的改进的关键的快速反馈是多么有用**。如果这能满足你对这些信息的胃口，那么一定要看看其他的RUM产品，看看它们能如何帮助你。

在研究其他的测量方法和RUM产品时，请记住要回过头来看看谷歌对你的网站是怎么看的，因为它很可能是不同的。如果在性能上努力工作，但同时却没有得到所有的排名好处，那就太可惜了！因此，请密切关注搜索控制中心的信息。因此，请密切关注搜索控制台的图表，以确保你不会错过任何东西。

结论

核心网络指标是一组有趣的关键指标，旨在代表用户浏览网络的体验。作为一个热衷于网络性能的倡导者，我欢迎任何改善网站性能的努力，而这些指标的排名影响无疑在网络性能和SEO社区创造了一个巨大的嗡嗡声。

虽然这些指标本身非常有趣，但更令人兴奋的是使用CrUX数据来衡量这些指标。这基本上将RUM数据暴露给那些以前甚至从未考虑过以这种方式测量网站性能的网站。RUM数据是用户在各种不同的设置中_实际体验到_的东西，了解你的网站是如何真正执行和被用户体验到的，是无可替代的。

但我们长期以来一直依赖实验室数据的原因是，RUM数据_是有噪音的。CrUX为减少噪音所采取的措施确实有助于提供一个更稳定的视图，但代价是它使我们很难看到最近的变化。

希望这篇文章能在一定程度上解释为您的网站访问Core Web Vitals数据的各种方法，以及每种方法的一些限制。我也希望它能在一定程度上解释一些你一直在努力理解的数据，以及建议一些方法来解决这些限制。

祝你优化工作顺利!