结合使用 Google 工具，有效审核、改进和监控您的网站。
发布时间：2020 年 5 月 28 日
核心 Web 指标是一组用于评估用户体验的指标，评估标准包括加载性能、对用户输入的响应速度和布局稳定性。
本指南将探讨改进您网站核心 Web 指标的工作流程，但该工作流程的起点取决于您是否收集自己的现场数据。其终点可能取决于您认为哪些 Google 工具在诊断和修复用户体验问题方面有用。
核心 Web 指标最好在现场进行测量
核心 Web 指标专门用于衡量用户如何体验您的网站，它们是用户中心指标。诸如 Lighthouse 等基于实验室的工具是诊断工具，用于突出显示潜在的性能问题和最佳实践。基于实验室的工具在某些预定义条件下运行，可能无法反映您的用户体验到的真实核心 Web 指标测量值。
例如，Lighthouse 是一种基于实验室的工具，它在模拟的桌面或移动环境中通过模拟节流运行测试。虽然这种对较慢网络和设备条件的模拟在尝试诊断性能问题时很有用，但它们只是网络条件和设备功能多样性中的一小部分，因此可能无法反映您网站上的用户正在体验的内容。
诸如 Lighthouse 等基于实验室的工具通常也会对网页进行“冷加载”，就像全新的访问者一样。这通常是最慢的加载，但在现实生活中，如果访问者之前访问过，或者当他们在网站上浏览时，他们可能已经缓存了一些资源。新访问者和工具也可能会因 Cookie 横幅或其他呈现给他们的内容而体验到不同的网站。
简而言之，虽然基于实验室的工具可以指示潜在的性能问题，并帮助您调试和迭代，但它们可能无法代表实际体验您网站的访问者数量。使用现场数据来衡量真实世界的性能，并使用诸如 Lighthouse 等基于实验室的工具来诊断如何改进它。另请参阅“何时使用 Lighthouse”部分。
Google 通过Chrome 用户体验报告 (CrUX) 来衡量核心 Web 指标。这是一个从真实 Chrome 用户收集的公共数据集。它是许多 Google 和第三方工具报告网站核心 Web 指标的支柱。
不过，CrUX 也有其局限性。它通常可以告诉您何时出现问题，但通常没有足够的数据来告诉您为什么。
如果可以，请收集您自己的现场数据
改进网站现场性能的最佳数据集是您构建的数据集。这始于从您网站的访问者那里收集现场数据。如何做到这一点取决于您组织的规模，以及您是想为第三方解决方案付费还是创建自己的解决方案。
付费解决方案几乎肯定会衡量核心 Web 指标（和其他性能指标），并且通常提供各种工具来深入研究结果数据。在拥有大量资源的大型组织中，这可能是首选方法。
但是，您可能不属于大型组织，甚至没有能力负担第三方解决方案。在这些情况下，Google 的web-vitals 库 将帮助您收集所有 Web 指标。但是，您将负责如何报告、存储和分析这些数据。
如果您已经在使用 Google Analytics，但您尚未开始收集自己的现场数据，那么您可能有机会使用web-vitals 库将现场收集的 Web 指标发送到 Google Analytics，并使用GA4 的 BigQuery 导出来报告数据。
了解 Google 的工具
无论您是否收集自己的现场数据，都有几种 Google 工具可能有助于分析核心 Web 指标。在建立工作流程之前，对每种工具进行高级概述可以帮助您了解哪些工具可能（或可能不）最适合您。
Chrome 用户体验报告 (CrUX)
如前所述，CrUX 是一个公共数据集，其中包含从数百万个网站的一部分真实 Google Chrome 用户收集的现场数据。它包括核心 Web 指标以及其他具有足够流量的网站的指标。
CrUX 在来源级别以每月BigQuery 数据集的形式提供，或者在 URL 或来源级别以每日 API 的形式提供，前提是 URL 或来源在 CrUX 数据集中有足够的样本。CrUX 数据可通过各种 CrUX 工具获得，用于程序化访问和供用户使用的可视化工具。
何时使用 CrUX
即使您收集自己的现场数据，CrUX 仍然有用。虽然 CrUX 代表 Chrome 用户的一个子集，但将您网站的现场数据与 CrUX 数据进行比较以查看其是否一致会很有帮助。每种方法都有其优点和缺点，这可能会导致差异。如果您没有为您的网站收集任何现场数据，那么 CrUX 特别有价值，可以提供高级概述——前提是您的网站在它的数据集中有代表。
您可以直接使用 CrUX，或者使用其他工具（包括下面提到的工具）。直接使用 CrUX 数据集，无论是使用 BigQuery 还是 API，都很有用，可以公开其他工具中未显示的数据——例如，国家/地区级别的数据通常在其他工具中不可用，或者查看CrUX 中的其他指标，这些指标通常也不会在其他工具中显示。
何时不使用 CrUX
CrUX 仅代表 Chrome 用户，即使这样，也只代表 Chrome 用户的一个子集。完整的 RUM 解决方案可以包括 Chrome 和其他支持 Web 指标的浏览器中的更多体验。
流量不足的网站不会在 CrUX 数据集中显示。如果您的网站属于这种情况，您将需要收集自己的现场数据以了解您的网站在现场的表现，因为 CrUX 将不是一个选项。或者，您将需要依赖实验室数据，但正如前面所述，实验室数据可能不具有代表性。
由于 CrUX 提供的数据是过去 28 天的滚动平均值，因此它不是开发期间的理想工具，因为改进需要相当长的时间才能反映在 CrUX 数据集中。
最后，作为一个公共数据集，CrUX 限制了它可以提供多少信息，以及如何查询这些数据。捕获您自己的 RUM 数据可以让您收集更多详细信息（例如，LCP 元素），并对数据进行更多细分以识别问题。登录用户体验到的核心 Web 指标比注销用户更好还是更差？LCP 较慢的用户是否有特定的 LCP 元素？哪些交互导致较高的 FID 和 INP 值？
PageSpeed Insights (PSI)
PSI 是一个工具，用于报告给定页面的 CrUX 的现场数据和 Lighthouse 的实验室数据。有关更多详细信息，请参阅这些单独的部分。
何时使用 PSI
PSI 非常适合评估移动和桌面用户的页面级别或来源级别的 CrUX 性能。它是页面或网站核心 Web 指标的初始概述的不错选择。它还允许您查看其他网站（如竞争对手）的核心 Web 指标数据。
PSI 还提供 Lighthouse 数据，如果指标一致，这将为改进您的核心 Web 指标提供有用的建议。如果这些指标不一致，Lighthouse 建议可能不太相关。
由于 Lighthouse 是从服务器运行的，因此它可以形成比从 DevTools 运行 Lighthouse 更一致的基线。
何时不使用 PSI
PSI 仅适用于公共 URL。它不能用于无法公开访问的开发站点。
只有当网站满足某些资格标准（包括网站受欢迎程度阈值）时，CrUX 数据才可用。当页面或来源没有 CrUX 数据时，PSI 的用处较小，因为它在这些情况下只能显示 Lighthouse 实验室数据。
同样，如果您只有来源级别的 CrUX 数据，而不是正在测试的特定 URL，那么这也限制了将来源级别的现场数据与页面级别的实验室诊断相关联的有用性。拥有来源级别的现场数据仍然是非常有用的信息，可以作为网站性能的摘要，Lighthouse 审核可能会有所帮助，但在这种情况下应格外小心。
最后，当页面级别的 CrUX 数据可用，但与 Lighthouse 实验室数据不同时，Lighthouse 的建议可能价值有限。这尤其可能发生在后加载 CLS 问题以及交互性核心 Web 指标（FID 和 INP）中，在这些情况下，基于实验室的审核不太有用。
Search Console
Search Console 衡量您网站的搜索流量和性能，包括核心 Web 指标。它仅适用于已确认其网站所有权的网站所有者。
Search Console 的一个有价值的功能是，它将相似的页面（例如，使用相同模板的页面）分组到单个组评估中。Search Console 还包括基于 CrUX 现场数据的核心 Web 指标报告。
何时使用 Search Console
Search Console 非常适合开发人员和非开发人员角色，以 Google 其他工具无法实现的方式评估搜索和页面性能。它对 CrUX 数据的呈现以及按相似性对页面进行分组，为性能改进如何影响整个页面类别提供了新颖的见解。
何时不使用 Search Console
对于使用不同的第三方工具按相似性对页面进行分组的项目，或者如果网站未在 CrUX 数据集中表示，则 Search Console 可能不适用。
当组中的示例页面与组中其余页面具有不同的特征时，页面分组也可能有些令人困惑——例如，如果组总体上未能通过特定的核心 Web 指标，但示例页面似乎都通过了相同的核心 Web 指标。当组包含长尾或很少访问的页面时，可能会发生这种情况，这些页面可能加载速度较慢，因为它们不太可能被缓存。当长尾中存在大量这些页面时，它们会影响组的总体通过率。
Lighthouse
Lighthouse 是一个实验室工具，可为改进页面性能提供具体的机会。Lighthouse 用户流还允许开发人员编写交互流程脚本，以便在页面加载之外进行性能测试。
Lighthouse-CI 是一个相关工具，可在项目构建和部署期间运行 Lighthouse，以协助进行性能回归测试。它会提供 Lighthouse 报告以及拉取请求，并随时间跟踪性能指标。
何时使用 Lighthouse
Lighthouse 非常适合在本地和暂存环境的开发过程中查找性能改进机会。Lighthouse CI 在构建和部署阶段对于暂存和生产环境也同样有用，在这些环境中，需要进行性能回归测试以保持良好的用户体验。
何时不使用 Lighthouse
Lighthouse（或 Lighthouse CI）不是现场数据的替代品。Lighthouse 主要是一个诊断工具，列出了预定义页面加载的潜在问题和最佳实践。它提出的建议可能并不总是与您的用户体验到的性能相匹配。
虽然可以使用 Lighthouse 通过诸如 PageSpeed Insights 等工具诊断生产站点，但理想情况下，Lighthouse 应该在开发和持续集成环境中使用，以在性能问题到达生产环境之前解决它们。
Lighthouse 提供的审核也通过 Chrome DevTools 中“性能”面板中的“insights”提供，这可以更深入地分析页面的性能。
Chrome DevTools 中的性能面板
Chrome DevTools 是浏览器内开发工具的集合，包括性能面板。性能面板是一个实验室工具，由两种“模式”组成
当首次打开性能面板时，“实时指标”屏幕会提供当前核心 Web 指标，并能够从 CrUX 导入现场数据。当您与页面交互以尝试发现性能问题时，它可以用作性能的“实时”视图，特别是对于您可能在 CLS 和 INP 指标中看到的后加载问题。
其次，性能面板允许开发人员捕获页面加载期间或记录的时间段内所有页面活动的配置文件（或跟踪）。此视图深入了解其在网络、渲染、绘制和脚本活动以及页面核心 Web 指标等维度上观察到的一切。它还包括 insights，类似于 Lighthouse 提供的 insights。
何时使用性能面板
开发人员应使用性能面板来深入了解特定页面的性能。
实时指标视图可用于快速了解页面的当前性能特征，并发现与页面交互时可能出现的问题。
跟踪视图对于调试影响 INP 的响应速度问题特别有用。一旦识别出响应不佳的交互并且可以重复，性能面板就可以提供大量关于浏览器中正在发生的事情的数据，以帮助理解问题，从主线程阻塞到 JavaScript 调用堆栈再到渲染工作。
何时不使用性能面板
性能面板是一个开发人员工具，主要提供实验室数据，尽管有一些来自 CrUX 的现场上下文。它不能替代现场数据。
跟踪视图包含大量调试信息，但正因为如此，对于新手开发人员或非开发人员角色来说，它可能难以理解。但是，面板打开时的实时指标视图通过为不需要完整详细信息的用户提供更易于使用的界面来解决此问题。
确保您网站的核心 Web 指标保持健康的三步工作流程
在努力改进用户体验时，最好将该过程视为一个持续的循环。为了改进核心 Web 指标和其他性能指标，一种方法可能是
- 评估网站健康状况并找出痛点。
- 调试和优化。
- 使用持续集成工具进行监控，以捕获和防止回归。
步骤 1：评估网站健康状况并找出改进机会
最好从实际现场数据开始评估网站健康状况。
- 使用 PageSpeed Insights 查看来源的整体 Core Web Vitals 体验指标，以及关于单个网址的具体信息。
- Search Console 可以帮助您找出需要改进的网页，其网页分组功能非常适合您的网站。
- 如果您有 RUM 数据，那么这通常是识别存在问题的特定网页或流量细分群体的最佳选择。
无论您分析自己收集的现场数据还是 CrUX 数据，第一步都至关重要。如果您没有收集现场数据，CrUX 数据可能足以指导您——前提是您的网站在数据集中有代表性。
使用 PageSpeed Insights 分析网站性能
PageSpeed Insights 显示 CrUX 数据，涵盖过去 28 天在第 75 百分位数的用户体验数据。这意味着，如果 75% 的用户体验满足给定指标的阈值，则该体验被认为是“良好”的。
如果您心中已经有要查看其性能的特定网页，请使用该网页。对于首次开始优化时网站的整体概览，您可能希望从首页开始，因为它通常是许多网站上最受欢迎的网页之一。
最初专注于 PSI 的“您的真实用户体验”部分。您将看到最多四个数据视图：针对输入的网址和整个来源的移动设备和桌面设备。比较这些视图，看看它们有何不同。移动设备的性能通常低于桌面设备，因为它是一种资源受限的设备，可能在不太稳定的网络条件下运行。如果网址和来源数据差异很大，请尝试了解原因：首页通常是访问的第一个网页（即着陆页），因此可能比来源用户完全承受未预热浏览器缓存的影响速度更慢。后续网页可能会加载得更快，因为任何共享资源都将被缓存，从而降低聚合的来源级别数据。
PSI 还显示所有三个 Core Web Vitals（LCP、CLS 和 INP）以及诊断性 TTFB 和 FCP 指标。是否有任何 Core Web Vitals 未能达标，以及未达标的程度？这将指示您应该集中精力的地方。
了解这些数字之间的关系——特别是对于 LCP。如果 LCP 速度慢，就像本例中一样，请查看 TTFB 和 FCP，这两个指标都是该指标的里程碑。在本例中，我们的 TTFB 为 1.8 秒，这将使得很难达到 2.5 秒的良好 LCP 建议阈值。这表明后端速度慢（服务器问题或缺少 CDN）、网络速度较慢或重定向延迟了第一个 HTML 字节。有关更多信息，请参阅优化 TTFB 指南。FCP 在此基础上又花费了一秒，这再次可能表明网络速度较慢。在本例中，LCP 在 FCP 之后不久，这表明 LCP 资源在网页本身加载后得到了很好的优化。CrUX 现在还在资源类型和子部分中显示更多诊断信息，这也有助于您诊断 LCP 问题。
对于 CLS，查看 CrUX CLS 和 Lighthouse CLS 分数，以查看这是否是加载 CLS 问题（Lighthouse 将捕获并提供建议），还是 Lighthouse 不会捕获的加载后 CLS 问题。有关更多信息，请参阅优化 CLS 指南。
对于响应性，请查看 INP 分数。查看 Lighthouse 中的 TBT 审核，以查看初始页面加载期间是否发生了大量 JavaScript 处理，这可能会影响 INP。INP 可能是一个难以改进的指标，因此请查阅优化 INP 指南以获取更多信息。
在 Search Console 中识别性能不佳的网页
虽然当您有要测试的特定网址或整个网站时，PSI 非常有用，但 Search Console 可以帮助您将精力集中在特定类型的网页上。如果许多网页共享共同的主题或技术，并且 Search Console 可以成功识别这些网页，则此功能尤其有用。
Search Console 中的 Core Web Vitals 报告显示了您网站性能的整体情况，但您仍然可以深入了解需要关注的特定网页。使用 Search Console，您还可以
- 识别需要改进的单个网页组，以及提供良好用户体验的网页组。
- 获取按状态、指标和相似网页组（例如电子商务网站上的产品详细信息页）分组的网址的精细性能数据。
- 获取详细报告，其中按移动设备和桌面设备的用户体验质量类别对网址进行分类。
一旦您有一些要查看的特定网页，您可以按照之前解释的方式使用 PSI 来进一步了解这些网页的问题。
步骤 2：调试和优化
在步骤 1 中，您应该已经确定了需要改进性能的网页，以及您想要改进的 Core Web Vitals 指标。您可以使用 Google 工具来获取更多信息，以了解根本原因并找出问题。
- 查看 Lighthouse 审核，获取网页的高级指导
- 使用 Performance 面板实时指标视图来实时分析 Core Web Vitals。
- 使用 Performance 面板跟踪来调试性能问题并测试代码更改。
有关更详细的指导，请参阅以下指南
通过 Lighthouse 发掘机会
PageSpeed Insights 为您运行 Lighthouse。也可以从 Chrome DevTools 运行 Lighthouse，这对于在本地验证修复非常有用，但 Performance 面板（接下来介绍）是用于在本地识别和修复性能问题的更全面的工具。
关键是要验证 Lighthouse 审核是否重现了您尝试解决的问题（例如，LCP 缓慢或 CLS 问题）。开箱即用，Lighthouse 仅评估页面加载期间的用户体验。由于它是一个实验室工具，因此它还在评估中排除了 INP，而倾向于使用 TBT。
当 Lighthouse 指标表明存在与您尝试解决的问题类似的问题时，其审核中丰富的信息可以帮助识别问题并提出解决方案。
您可以筛选审核，仅显示您感兴趣的 Core Web Vitals，以专注于修复与特定指标相关的问题
对于 INP，使用 TBT 审核来识别可能影响这些指标的问题，但请注意，在没有交互的情况下，Lighthouse 在诊断方面受到限制。
使用 Chrome DevTools 实时指标屏幕进行实时分析
Chrome DevTools Performance 面板中的实时指标屏幕在页面加载期间以及浏览页面时实时显示 Core Web Vitals。因此，它可以捕获 INP 以及加载后发生的布局偏移。还可以查看有关每个指标的更详细信息
此视图提供了许多有用的信息，可帮助识别性能问题，甚至可以从 CrUX 中提取现场信息。为了获得更多信息，您可以使用跟踪进行深入分析。
使用 Performance 面板进行深入分析
Chrome DevTools 中的 Performance 面板允许您记录在记录的时间段内所有页面行为的配置文件（或跟踪）。
性能洞察信息在“Insights”侧面板中可用。这也显示了 Core Web Vital 指标以及可用时的这些指标的现场值。
“Layout Shifts”轨道突出显示了布局偏移，单击这些偏移可提供有关已偏移元素的更多详细信息，以便调试 CLS。
关键时间点（例如 LCP）显示在跟踪底部的“Timings”中。单击这些时间点可获得更多详细信息。
长任务（可能导致 INP 问题）也在火焰图中用红色三角形突出显示。
这些功能——以及Performance 面板其他部分的信息——可以帮助您确定修复是否对网页的 Core Web Vitals 产生任何影响。
在现场调试 Core Web Vitals
实验室工具并不总是能够识别影响用户的所有 Core Web Vitals 问题的根源。这就是收集您自己的现场数据如此重要的原因之一，因为它考虑了实验室数据无法考虑的因素。
有关更多信息，请参阅在现场调试性能。
步骤 3：监控更改
一旦您修复了任何问题，您就需要确保它们产生了所需的效果，并且新问题不会扰乱您的 Core Web Vitals。这需要将性能问题监控作为开发者工作流程的一部分，以防止性能问题发布到生产环境，并定期监控现场数据以确保情况如此。
在持续集成 (CI) 环境中监控性能需求
Lighthouse-CI 使您可以自动在代码提交时运行 Lighthouse 审核，以防止性能退化进入代码。这可以检查性能计时（这些计时可能会发生变化），或者仅检查性能审核，作为一种代码检查工具，以防止代码中出现不良做法。
使用现场数据查看网站健康状况趋势
虽然您应该力求在所有性能问题进入生产环境之前捕获并修复它们，但使用 RUM 监控您的现场数据对于发现任何遗漏的问题至关重要。有许多商业 RUM 产品可用于帮助您实现此目的。web-vitals JavaScript 库可以自动化网站的现场数据收集，并可以选择使用此数据来支持自定义仪表板和警报系统。
对于没有 RUM 解决方案的网站，您可以使用各种 CrUX 工具作为现场数据的基本趋势分析。
结论
确保快速且令人愉悦的用户体验需要以性能为先的心态，并采用工作流程来确保进步。借助正确的工具和流程来进行审核、调试和监控，构建出色的用户体验并保持在为良好的 Core Web Vitals 定义的阈值范围内是您可以实现的。