结合 Google 工具实现高效的网站审核、优化与监控

发布日期：2020年5月28日

核心网页指标（Core Web Vitals）是一系列以加载性能、用户输入响应性和布局稳定性等标准来评估用户体验的指标。

本指南将详细介绍改善网站 Core Web Vitals 的工作流程。根据您是否已收集自有真实用户数据（field data），工作流程的起点会有所不同。具体能执行到哪一步，取决于 Google 提供的各类有助于诊断和修复用户体验问题的工具。

核心网页指标应基于真实用户环境进行测量

核心网页指标是专门设计的、以用户为中心的指标，用于衡量用户实际如何体验您的网站。而像 Lighthouse 这样的实验室工具属于诊断工具，用于高亮显示潜在的性能问题或最佳实践。由于实验室工具在特定的、预定义条件下运行，其结果可能无法反映用户实际体验到的核心网页指标。

• 实验室数据：展示了虚拟用户可能如何体验您的网站。
• 真实用户数据：展示了真实用户实际上是如何与您的网站互动的。

真实用户数据通常通过真实用户监控（RUM）收集，即利用用户加载页面时执行的 JavaScript 来监控实际用户体验，并将各项指标上报至分析解决方案。

以 Lighthouse 为例，它是在模拟的桌面或移动环境中，使用模拟节流（throttling）进行测试的实验室工具。虽然模拟慢速网络或设备条件有助于诊断性能问题，但这只是网络状况和设备性能多样性的一个子集，可能无法完全代表您网站用户的真实情况。

此外，像 Lighthouse 这样的实验室工具通常以“全新用户”的身份“冷加载”网页。这通常是最慢的加载场景，而实际上，回头客或站内浏览用户可能已缓存部分资源。新访客或工具也可能因为显示 Cookie 横幅等内容而看到不同的页面版本。

因此，实验室工具主要用于揭示潜在的性能问题，并辅助调试和迭代，但它们可能无法完全反映网站访问者的真实体验。最佳实践是：使用真实用户数据测量实际性能，同时利用 Lighthouse 等实验室工具诊断性能改进方法。您也可以参考何时使用 Lighthouse 章节。

Google 通过 Chrome 用户体验报告（CrUX）来测量核心网页指标。这是一个公开数据集，收集自真实 Chrome 用户，是许多 Google 及第三方工具报告网站 Core Web Vitals 的基础。

然而，CrUX 存在一些限制。我们通常能知道问题发生的时间点，但往往缺乏足够的数据来确定根本原因。

尽可能收集自有真实用户数据

改善网站在真实环境中性能的最佳数据集，来源于您自己的用户。因此，首要步骤是从网站访问者那里收集真实用户数据。具体方法取决于组织规模，以及您是选择购买第三方解决方案还是自建方案。

付费解决方案几乎肯定会测量 Core Web Vitals（以及其他性能指标），并通常提供各种工具来深入分析结果数据。对于资源充足的大型组织，推荐采用此方法。

如果您不属于大型组织，或没有预算引入第三方解决方案，可以使用 Google 的 web-vitals 库来收集所有核心网页指标。但数据的上报、存储和分析需要您自行负责。

如果您计划构建自己的指标收集和报告系统，建议阅读最佳实践指南以避免常见陷阱。

如果您已经在使用 Google Analytics 但尚未开始收集自有真实用户数据，可以尝试使用 web-vitals 库将在真实环境中收集的指标发送到 Google Analytics，并利用 GA4 的 BigQuery 导出功能进行数据报告。

Google 相关工具简介

无论您是否已收集自有真实用户数据，Google 都提供了一些有助于分析核心网页指标的工具。在建立工作流程前，了解每个工具的概览将帮助您判断哪个最适合（或不适合）您的需求。

您无需使用本指南中提到的所有工具，只需选择那些有助于改善您网站核心网页指标的工具即可。

Chrome 用户体验报告（CrUX）

如前所述，CrUX 是一个公开数据集，包含从数百万网站的部分真实 Chrome 用户收集的字段数据。它涵盖了具有足够流量的网站的 Core Web Vitals 指标及其他指标。

CrUX 可作为源（origin）级别的月度 BigQuery 数据集使用，或者在 URL 或源级别上拥有足够样本量的前提下，通过每日 API 获取。用户可以通过编程方式访问 CrUX 数据，或使用各种面向用户的可视化 CrUX 工具。

何时使用 CrUX

即使您已收集自有真实用户数据，CrUX 仍然有用。虽然 CrUX 仅代表部分 Chrome 用户，但将其与您网站的数据进行比较，观察其吻合程度，是很有价值的实践。两者各有优劣，结果可能存在差异。

如果您完全没有收集网站的真实用户数据，CrUX 对于了解概况特别有帮助，前提是您的网站包含在该数据集中。

您可以直接使用 CrUX 数据集（通过 BigQuery 或 API），这有助于揭示其他工具未展示的数据（例如，国家/地区级别的数据通常在其他工具中不可用），或查看 CrUX 的附加指标（这些指标也常常在其他工具中不显示）。

何时不应使用 CrUX

CrUX 仅代表 Chrome 用户，并且只是其中一部分。完整的 RUM 解决方案可以包含更多浏览器（包括 Chrome 和其他支持核心网页指标的浏览器）的用户体验。

流量不足的网站不会出现在 CrUX 数据集中。这种情况下，您无法使用 CrUX，必须收集自有真实用户数据才能了解网站的真实性能。或者，您只能依赖实验室数据，但如前所述，这存在代表性可能不足的限制。

CrUX 提供的数据是过去 28 天的滚动平均值，因此改进反映在 CrUX 数据集中需要相当长的时间，使其不太适合作为开发中的即时工具。

最后，作为公开数据集，CrUX 中可用信息的数量以及查询方式存在限制。捕获自有 RUM 数据可以让您收集更详细的信息（如 LCP 元素），并对数据进行更细粒度的细分以定位问题（例如：登录用户与未登录用户的 Core Web Vitals 表现是否有差异？LCP 慢的用户是否有特定的 LCP 元素？哪些交互导致了高的 FID 和 INP 值？）。

PageSpeed Insights（PSI）

PSI 是一个工具，可报告指定页面的 CrUX 真实用户数据和 Lighthouse 实验室数据。详情请参阅各工具介绍部分。

何时使用 PSI

PSI 适用于在页面级别或源级别评估 CrUX 性能，涵盖移动端和桌面端用户。它是了解页面或网站核心网页指标概况的良好选择。您还可以查看竞争对手等其他网站的核心网页指标数据。

PSI 也提供 Lighthouse 数据。当实验室数据和真实用户数据指标一致时，Lighthouse 提供的建议对于改进核心网页指标非常有帮助。如果两者不一致，Lighthouse 建议的相关性可能会降低。

由于 Lighthouse 是从服务器端运行的，因此相比在 DevTools 中运行 Lighthouse，PSI 能提供更一致的基准。

何时不应使用 PSI

PSI 仅适用于公开 URL，无法在未公开的开发站点上使用。

CrUX 数据仅在满足特定资格条件（如网站受欢迎程度阈值）时可用。如果页面或源没有可用的 CrUX 数据，PSI 将仅显示 Lighthouse 实验室数据，实用性会降低。

同样，如果只有源级别的 CrUX 数据，而没有针对测试的具体 URL 的数据，那么将源级别的真实用户数据与页面级别的实验室诊断关联起来的效用会受到限制。源级别的真实用户数据作为网站性能的概览非常有用，Lighthouse 审核也可能提供帮助，但在这种情况下需要特别谨慎。

最后，即使特定 URL 在 CrUX 中有页面级别的数据可用，但如果这些数据与 Lighthouse 实验室数据不同，则 Lighthouse 建议的价值可能有限。这在加载后发生的 CLS 问题以及交互性核心网页指标（FID 和 INP）上尤其可能发生，因为 Lighthouse 的实验室审核对于这些指标的帮助可能不大。

Search Console

Search Console 允许您衡量网站的搜索流量和性能（包括核心网页指标）。此功能仅限经过网站所有权验证的网站所有者使用。

Search Console 的一个便利功能是能够将相似的页面（例如，使用相同模板的页面）汇总到一个组评估中。它还包括基于 CrUX 真实用户数据的 Core Web Vitals 报告。

何时使用 Search Console

Search Console 适合开发者和非开发者角色用户评估搜索和页面性能，这是其他 Google 工具无法替代的。通过查看 CrUX 数据以及基于相似性的页面分组，您可以获得关于性能改进对整个页面类别影响的新见解。

何时不应使用 Search Console

如果您的项目已使用其他基于相似性对页面进行分组的第三方工具，或者您的网站未出现在 CrUX 数据集中，那么 Search Console 可能不适合。

当组内样本页面的特性与组内其他页面不同时（例如，整个组在特定核心网页指标上未达标，但样本页面看起来却全部达标），页面分组有时会变得复杂。这可能发生在组内包含长尾或访问频率低的页面时，这些页面缓存可能性较低，加载时间可能更长。如果长尾中有足够多的此类页面，可能会影响组的整体达标率。

Lighthouse

Lighthouse 是一个实验室工具，它提供改善页面性能的具体方法。使用 Lighthouse 用户流程，开发者还可以编写交互流程的脚本，用于测试页面加载之外的其他性能场景。

由于 Lighthouse 是实验室工具，而 INP 是真实用户环境指标，因此 Lighthouse 报告的是 Total Blocking Time。

Lighthouse-CI 是一个相关工具，可在项目构建和部署期间运行 Lighthouse，以帮助进行性能回归测试。它可以在拉取请求中显示 Lighthouse 报告，并跟踪性能指标随时间的变化趋势。

何时使用 Lighthouse

Lighthouse 非常适合在开发期间，于本地环境和 staging 环境中发现性能改进机会。同样，Lighthouse CI 在构建和部署阶段对 staging 和生产环境都有帮助。性能回归测试对于维持良好的用户体验至关重要。

请注意，不应仅使用 Lighthouse CI 部署到生产环境，否则可能会错过在开发期间于本地或 staging 环境中通过 Lighthouse 检测到的性能回归。

何时不应使用 Lighthouse

Lighthouse（或 Lighthouse CI）不能替代真实用户数据。Lighthouse 主要作为诊断工具使用，列出预定义页面加载过程中的潜在问题和最佳实践。所显示的优化建议不一定与实际用户体验的性能完全对应。

请始终优先考虑真实环境中的 Core Web Vitals，而不是 Lighthouse 的指标或分数。特别是，Lighthouse 性能分数是其实验室测试中广泛指标的综合，常常与真实环境的核心网页指标没有直接关联。

虽然可以使用 Lighthouse（通过 PageSpeed Insights 等工具）对生产环境站点进行诊断，但理想情况下，应在开发和持续集成环境中使用 Lighthouse，以便在生产环境上线前解决性能问题。

Lighthouse 提供的审核信息，也可以在 Chrome DevTools 性能面板的“Insights”部分找到。后者允许对页面性能进行更深入的分析。

Chrome DevTools 性能面板

Chrome DevTools 是一套浏览器内置的开发工具集合，其中包括性能面板。性能面板是一个实验室工具，由两种“模式”组成：

首次打开性能面板时，您会看到“实时指标”屏幕，其中显示当前的 Core Web Vitals 指标。您还可以从 CrUX 导入真实用户数据。这有助于在操作页面时，以性能“实时”视图识别问题，特别是加载后出现的问题（可在 CLS 和 INP 指标中观察到）。

其次，在性能面板中，您可以捕获页面加载期间或记录时间段内所有页面活动的配置文件（或跟踪）。在此视图中，您可以查看所有维度的观测信息（如网络、渲染、绘制、脚本活动）以及页面 Core Web Vitals 的深入分析见解。它也包含与 Lighthouse 提供的类似的洞察。

何时使用性能面板

性能面板是开发者获取特定页面性能详细洞察所必需的工具。

• 实时指标视图：可快速了解页面当前的性能特性，并在页面交互过程中发现潜在问题。
• 跟踪视图：在调试影响 INP 的响应性问题时尤其有用。一旦识别出并可以复现响应缓慢的交互，您就可以在性能面板中查看浏览器中发生的丰富数据，获得有助于理解问题的信息，如主线程阻塞、JavaScript 调用堆栈、渲染工作等。

何时不应使用性能面板

性能面板主要是一个提供实验室数据的开发者工具（尽管也包含部分 CrUX 真实用户数据背景）。它不能替代真实用户数据。

虽然跟踪视图包含大量调试信息，这可能使其对初学者开发者或非开发者角色的用户难以理解。不过，面板初始打开的实时指标视图通过提供用户友好的界面来解决这个问题，适用于不需要深入细节的用户。

保持网站核心网页指标健康的 3 步工作流程

在致力于改善用户体验时，建议将流程视为一个持续的循环。以下是一种改进 Core Web Vitals 和其他性能指标的可行方法：

1. 评估网站健康状况并识别问题。
2. 调试和优化。
3. 通过持续集成工具进行监控，以检测和防止回归。

步骤 1：评估网站健康状况，识别改进机会

建议从真实用户数据开始评估网站健康状况。

• 使用 PageSpeed Insights 查看源级别的核心网页指标整体体验数据，以及针对单个 URL 的具体信息。
• Search Console 有助于识别需要改进的页面。其页面分组功能在站点层面有效运作。
• 如果您有 RUM 数据，这是识别有问题的特定页面或流量细分的最佳方式。

无论您是分析自己收集的真实用户数据还是 CrUX 数据，这第一步都至关重要。如果您没有收集真实用户数据，CrUX 数据可能提供足够的指导，前提是您的网站包含在数据集中。

使用 PageSpeed Insights 分析网站性能

PageSpeed Insights 显示 CrUX 数据，该数据代表过去 28 天内用户体验数据的第 75 百分位值。这意味着，如果 75% 的用户体验满足特定指标的设定阈值，则该体验被视为“良好”。

如果您有特定的页面需要检查性能，请使用该页面。为了在开始优化时了解网站全貌，建议从主页开始，这通常是大多数网站最受欢迎的页面之一。

首先关注 PSI 中“真实用户评估”部分。您将看到针对输入的 URL 和整个源的四个视图（移动端和桌面端）的数据。比较这些视图以识别差异。移动设备通常是资源受限且网络稳定性可能较差的设备，因此其性能通常低于桌面端。如果 URL 和源的数据差异很大，请努力理解其原因。主页通常是首次访问的页面（着陆页），因此可能比源级别的数据表现更差，因为用户会感受到浏览器缓存未准备好的影响。后续页面加载可能更快，因为共享资源可能已被缓存，从而降低了源级别聚合数据。

PSI 还显示所有三个核心网页指标（LCP、CLS、INP），以及用于诊断的 TTFB 和 FCP 指标。

• 观察是否有任何核心网页指标未达标，或者距离达标有多远。这有助于确定工作的重点。
• 理解这些数值之间的关系，特别是 LCP。如果 LCP 较慢（如此示例），请检查该指标的关键里程碑 TTFB 和 FCP。在此示例中，TTFB 为 1.8 秒，这使得满足 LCP 推荐阈值（2.5 秒）变得非常困难。这表明可能存在后端慢（服务器问题或缺少 CDN）、网络慢或重定向导致初始 HTML 字节延迟。FCP 又额外花费了 1 秒，这也可能表明网络缓慢。在此示例中，LCP 紧随 FCP 之后，这表明页面本身加载后，LCP 资源得到了适当的优化。现在，CrUX 也提供了更多的诊断信息，如资源类型和子部分，这也有助于诊断 LCP 问题。
• 对于 CLS，请检查 CrUX CLS 和 Lighthouse CLS 的分数，以判断是加载时的 CLS 问题（Lighthouse 可以检测并提供建议）还是加载后的 CLS 问题（Lighthouse 无法检测到）。详情请参阅优化 CLS 的指南。
• 对于响应性，请查看 INP 分数。检查 Lighthouse 的 TBT 审核是否显示页面首次加载时执行了大量 JavaScript 处理，这可能会影响 INP。由于 INP 是一个难以改进的指标，请参考INP 优化指南以获取详细信息。

使用 Search Console 识别性能不佳的页面

虽然 PSI 在您有特定 URL 或整个站点需要测试时很有用，但 Search Console 允许您针对特定类型的页面采取措施，特别是在许多页面使用共同主题或技术且 Search Console 能正确识别它们的情况下，这一点尤其有效。

Search Console 的 Core Web Vitals 报告不仅显示网站性能的整体情况，还允许您深入查看需要注意的特定页面。在 Search Console 中，您还可以：

• 识别需要改进的单个页面组，以及提供良好用户体验的页面组。
• 获取按状态、指标和类似网页组（例如，电子商务网站的产品详情页）分组的 URL 性能的详细数据。
• 获取详细报告，其中 URL 按每种用户体验质量类别分类（适用于移动端和桌面端）。

Search Console 中显示的数据可能与 PageSpeed Insights 的源视图或其他 CrUX 工具不同。这是因为 Search Console 按 URL 组整理信息，而 PageSpeed Insights 视图和其他 CrUX 工具则按 URL 或源整理数据。

因此，有时 Search Console 可能只显示少数性能不佳的 URL，即使这些 URL 占了总流量的大部分，而在其他 CrUX 工具中可能会显示源级别用户体验不佳的比例较高。

在检查特定页面时，可以如前所述使用 PSI 来更深入地了解这些页面存在的问题。

步骤 2：调试与优化

在步骤 1 中，您应该已经识别出需要改进性能的页面以及您希望优化的核心网页指标。您可以使用 Google 工具获取详细信息，以了解根本原因并确定问题。

• 通过 Lighthouse 审核获取页面概览。
• 使用性能面板的实时指标视图实时分析 Core Web Vitals。
• 使用性能面板的跟踪来调试性能问题并测试代码更改。

有关详细指导，请参阅以下指南：

• 优化 LCP
• 优化 INP
• 优化 CLS

使用 Lighthouse 发现优化机会

PageSpeed Insights 会运行 Lighthouse。您也可以从 Chrome DevTools 运行 Lighthouse，这对于本地验证修复很有用。然而，性能面板（下面会介绍）是在本地识别和修复性能问题更全面的工具。

关键在于，确保您试图通过 Lighthouse 审核解决的问题（如 LCP 延迟、CLS 问题等）能够被复现。 默认情况下，Lighthouse 仅评估页面加载时的用户体验。作为实验室工具，它优先考虑 TBT 并排除了 INP。

默认情况下，Lighthouse 在节流的慢速 4G 连接上模拟中端移动设备。这有助于发现在高速设备或高速互联网连接上通常不会出现的问题。这种模拟的节流可能并不代表您网站用户群体中处于第 75 百分位的用户体验。然而，这些指标确实表明了性能问题存在的领域，解决 Lighthouse 发现的问题很可能会提升真实环境的整体性能。

如果 Lighthouse 的指标显示的问题与您试图解决的问题类似，那么审核提供的大量信息将有助于识别问题并提出解决方案。

您可以将审核过滤为仅关注您感兴趣的核心网页指标，从而专注于修复与特定指标相关的问题。

Lighthouse 过滤选项

对于 INP，可以使用 TBT 审核来识别可能影响这些指标的问题。但请注意，如果缺乏用户交互，Lighthouse 的诊断能力是有限的。

使用 Chrome DevTools 实时指标视图进行实时分析

Chrome DevTools 性能面板的“实时指标”屏幕会在页面加载期间和浏览页面时实时显示核心网页指标。因此，它不仅可以捕获加载后发生的布局偏移，还可以捕获 INP。您还可以查看每个指标的详细信息。

Chrome DevTools 性能面板的实时指标视图

此视图显示了大量有助于识别性能问题的信息。您还可以从 CrUX 获取真实用户信息。您也可以使用跟踪获取更详细的信息。

使用性能面板深入分析

在 Chrome DevTools 的性能面板中，您可以记录一段时间内所有页面活动的配置文件（或跟踪）。

Chrome DevTools 性能面板的跟踪视图

性能分析见解可以在“Insights”侧边面板中找到。还会显示核心网页指标以及该指标的字段值（如果可用）。

• 布局偏移轨道会高亮显示布局偏移。点击它们可以查看导致 CLS 的偏移元素的详细信息。
• LCP 等关键计时点显示在跟踪底部的“Timings”部分。点击它们可查看详情。
• 长任务（可能导致 INP 问题的任务）在火焰图中以红色三角形高亮显示。

这些功能，结合性能面板其他部分的信息，有助于判断您的修改是否对页面的核心网页指标产生了预期的影响。

调试真实用户环境中的核心网页指标

实验室工具不一定能找出影响用户的所有核心网页指标问题的根本原因。这正是收集真实用户数据至关重要的原因之一，因为它可以考虑实验室数据无法涵盖的因素。

有关更多信息，请参阅调试真实环境性能。

步骤 3：监控变更

修复问题后，您需要确保修复按预期生效，并且新问题不会阻碍核心网页指标。为此，您需要将性能问题监控作为开发工作流程的一部分，以防止性能问题发布到生产环境，并定期监控真实用户数据以确保没有回归。

Google 研究发现，大多数性能改进往往在六个月内回退。因此，网站需要在实验室和真实环境中进行持续监控，以识别性能恶化的趋势并避免回归。

在持续集成（CI）环境中监控性能要求

使用 Lighthouse-CI，您可以自动对代码提交运行 Lighthouse 审核，防止性能回归进入代码库。您可以检查性能计时（可能会有波动）或仅检查性能审核。它还可以作为 linting 工具，防止代码中出现不良实践。

通过真实用户数据监控网站健康状况趋势

目标是在迁移到生产环境之前检测并修复所有性能问题，但使用 RUM 监控真实用户数据对于确保没有遗漏至关重要。市场上有许多商业 RUM 产品对此有帮助。您也可以使用 web-vitals JavaScript 库来自动化收集网站的真实用户数据。您还可以利用这些数据来增强自定义仪表板和警报系统。

对于没有 RUM 解决方案的站点，您可以将各种 CrUX 工具用作真实用户数据的基础趋势分析。

即使您的网站出现在 CrUX 中，也建议收集自有真实用户数据，因为 CrUX 并不包含所有 Chrome 用户或其他浏览器的用户。但是，如果您没有真实用户数据，从 CrUX 开始是一个不错的选择。

总结

要提供快速、舒适的用户体验，必须将性能视为首要任务，并采用能够确保进展的工作流程。借助合适的工具和流程进行审核、调试和监控，完全有可能达到被定义为良好用户体验的核心网页指标阈值。