衡量实际网页指标的最佳做法

如何使用您当前的分析工具衡量网页指标。

Philip Walton

能够衡量和报告网页的实际效果对诊断和改进效果至关重要。如果没有实测数据，我们就无法确定您对网站所做的更改是否确实达到了预期效果。

许多热门的实时用户监控 (RUM) 分析服务提供商已经在其工具中支持核心网页指标（以及许多其他 Web Vitals）。如果您目前使用的是其中一种 RUM 分析工具，则可以很好地评估您网站上的网页在多大程度上符合建议的核心网页指标阈值，并防止日后出现回归问题。

虽然我们建议您使用支持 Core Web Vitals 指标的分析工具，但如果您目前使用的分析工具不支持这些指标，您不一定需要改用其他工具。几乎所有分析工具都提供了定义和衡量自定义指标或事件的方法，这意味着您可能可以使用当前的分析服务提供商衡量 Core Web Vitals 指标，并将其添加到现有的分析报告和信息中心。

本指南介绍了使用第三方或内部分析工具衡量 Core Web Vitals 指标（或任何自定义指标）的最佳实践。它还可为希望为其服务添加核心网页指标支持的分析供应商提供指导。

使用自定义指标或事件

如上所述，大多数分析工具都支持衡量自定义数据。如果您的分析工具支持此功能，您应该能够使用此机制衡量每个 Core Web Vitals 指标。

在分析工具中衡量自定义指标或事件通常是一个三步流程：

  1. 在工具的管理界面中定义或注册自定义指标（如果需要）。（注意：并非所有分析服务提供商都要求您提前定义自定义指标。）
  2. 在前端 JavaScript 代码中计算指标的值。
  3. 将指标值发送到您的分析后端，确保名称或 ID 与第 1 步中定义的名称或 ID 匹配（同样，如果需要）。

对于第 1 步和第 3 步，您可以参阅分析工具的文档，了解相关说明。在第 2 步中，您可以使用 web-vitals JavaScript 库计算每个 Core Web Vitals 指标的值。

以下代码示例展示了如何轻松地在代码中跟踪这些指标并将其发送到分析服务。

import {onCLS, onINP, onLCP} from 'web-vitals';

function sendToAnalytics({name, value, id}) {
  const body = JSON.stringify({name, value, id});
  // Use `navigator.sendBeacon()` if available, falling back to `fetch()`.
  (navigator.sendBeacon && navigator.sendBeacon('/analytics', body)) ||
      fetch('/analytics', {body, method: 'POST', keepalive: true});
}

onCLS(sendToAnalytics);
onINP(sendToAnalytics);
onLCP(sendToAnalytics);

避免使用平均值

人们往往倾向于通过计算平均值来汇总性能指标的一系列值。平均而言，一眼就能看出平均值，因为它们是大量数据的简洁摘要，但您应该抑制住这种冲动，不要依赖它们来解读网页性能。

平均值有问题，因为它们不代表任何单个用户的会话。分布范围的任一端点的离群值都可能会以误导性的方式使平均值偏离。

例如，一小部分用户可能使用的是极其缓慢的网络或接近最大值范围的设备，但其用户会话数不足以对平均值产生影响，因此不会导致系统认为存在问题。

请尽可能使用百分位数，而不是平均值。针对给定效果指标的整个分布范围的百分位数可以更好地描述您的网站的全面用户体验。这使您可以专注于实际体验的子集，从而比单个值能够让您获得更多的数据洞见。

确保您可以报告分发情况

计算每个核心网页指标的值并使用自定义指标或事件将其发送到您的分析服务后，下一步是构建一个报告或信息中心，以显示收集到的值。

为确保您达到推荐的核心网页指标阈值，您的报告需要显示每个指标的第 75 百分位的值。

如果您的分析工具未提供内置的百分位数报告，您或许仍可以通过生成一个按升序排列每个指标值的报告来手动获取此类数据。生成此报告后，该报告中所有值的完整排序列表中位于 75% 位置的结果将是该指标的第 75 个百分位数，无论您如何细分数据（按设备类型、连接类型、国家/地区等）都是如此。

如果您的分析工具默认不提供指标级报告粒度，那么如果您的分析工具支持自定义维度，您或许可以实现相同的结果。通过为您跟踪的每个指标实例设置一个唯一的自定义维度值，如果您在报告配置中添加自定义维度，则应该能够生成按各个指标实例细分的报告。由于每个实例都具有唯一的维度值，因此不会进行分组。

“网页指标”报告便是采用 Google Analytics 的方法之一。该报告的代码是开源的，因此开发者可以将其用作本部分中介绍的技术示例。

网页指标报告的屏幕截图

在合适的时间发送您的数据

有些性能指标可以在网页加载完毕后计算，而另一些指标（例如 CLS）则会考虑网页的整个生命周期，并且只有在网页开始卸载后才会最终确定。

不过，这可能会出现问题，因为 beforeunload 和 unload 事件不可靠（尤其是在移动设备上），不建议使用它们（因为它们可能会导致网页不符合使用往返缓存的条件）。

对于跟踪网页整个生命周期的指标，最好在每次网页的公开范围状态更改为 hidden 时，在 visibilitychange 事件期间发送该指标的当前值。这是因为，一旦网页的可见性状态变为 hidden，就无法保证该网页上的任何脚本能够再次运行。在移动操作系统上尤其如此，因为浏览器应用本身可能会关闭，而不会触发任何页面回调。

请注意，在切换标签页、切换应用或关闭浏览器应用本身时，移动操作系统通常会触发 visibilitychange 事件。它们还会在关闭标签页或导航到新页面时触发 visibilitychange 事件。这使得 visibilitychange 事件比 unload 或 beforeunload 事件可靠得多。

长期监控性能

更新分析实现以跟踪和报告 Core Web Vitals 指标后，下一步是跟踪网站更改对其一段时间内的性能有何影响。

对更改进行版本控制

跟踪更改的一种简单（且最终不可靠）的方法是将更改部署到生产环境，然后假定在部署日期之后收到的所有指标均对应于新网站，且部署日期之前收到的所有指标均对应于旧网站。但是，许多因素（包括 HTTP、Service Worker 或 CDN 层的缓存）都可能导致它无法正常运行。

更好的方法是为每个部署的更改创建一个唯一的版本，然后在分析工具中跟踪该版本。大多数分析工具都支持版本设置。如果您的版本不支持，您可以创建自定义维度，并将该维度设置为已部署的版本。

运行实验

您可以更进一步，同时跟踪多个版本（或实验）。

如果分析工具允许您定义实验组，请使用该功能。 否则，您可以使用自定义维度来确保每个指标值都可以与报告中的特定实验组相关联。

在分析中进行实验后，您可以向一部分用户发布实验性更改，并将该更改的效果与对照组用户的效果进行比较。当您确信某项更改确实可以提升效果后，就可以面向所有用户发布该更改。

确保衡量不会影响效果

在真实用户群中衡量性能时，所运行的任何性能衡量代码都不能对网页的性能产生负面影响，这一点至关重要。否则，您就无法了解分析代码本身的负面影响是否会最大。

在生产网站上部署 RUM 分析代码时，请始终遵循以下原则：

推迟分析

Google Analytics 代码应始终以异步、非阻塞的方式加载，并且通常应最后加载。如果您以阻塞方式加载分析代码，可能会对 LCP 产生负面影响。

用于衡量 Core Web Vitals 指标的所有 API 都经过专门设计，可支持异步和延迟脚本加载（通过 buffered 标志），因此无需急于尽早加载脚本。

如果您要衡量在网页加载时间轴的后续时间段内无法计算的指标，则应仅将需要尽早运行的代码内嵌到文档的 <head> 中（以便其不是呈现阻塞请求），并推迟其余代码。不要仅仅因为单个指标需要就提前加载所有分析数据。

不要创建长任务

Google Analytics 代码经常会在响应用户输入时运行，但如果您的分析代码执行大量 DOM 测量或使用其他处理器密集型 API，则分析代码本身可能会导致输入响应速度缓慢。此外，如果包含分析代码的 JavaScript 文件很大，执行该文件可能会阻塞主线程，并对网页的互动到下次绘制时间 (INP) 产生负面影响。

使用非阻塞 API

sendBeacon() 和 requestIdleCallback() 等 API 专门用于以不会阻止用户关键任务的方式运行非关键任务。

这些 API 非常适合在 RUM 分析库中使用。

通常，所有分析信标都应使用 sendBeacon() API（如果可用）发送，并且所有被动分析衡量代码都应在空闲期间运行。

不要跟踪超出需要的内容

浏览器会公开大量性能数据，但数据可用并不一定意味着您应该记录这些数据并将其发送到分析服务器。

例如，Resource Timing API 会提供网页上加载的每项资源的详细耗时数据。不过，这些数据不太可能全部对提升资源加载性能有必要或有用。

简而言之，请勿仅仅因为数据存在而跟踪数据，请先确保数据将被使用，然后再消耗跟踪数据的资源。