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