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

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

Philip Walton

能够衡量和报告网站的实际效果， 随着时间的推移，诊断和改善效果至关重要。不包含 字段 数据， 无法确切了解对网站所做的更改是否 是否取得了预期效果

许多流行的真实用户监控 (RUM) 分析服务提供商 Core Web Vitals 指标 工具（以及许多其他网页指标）。如果您 在使用上述 RUM 分析工具之一， 评估您网站上的网页在多大程度上满足建议的核心网页指标 阈值并防止回归 。

虽然我们建议使用支持 Core Web Vitals 的分析工具， 如果您当前使用的分析工具不支持这些指标， 并不一定需要进行转换几乎所有分析工具都提供了一种 定义和衡量自定义 指标或 事件，这表示 或许可以利用您当前的分析服务提供商来衡量核心网页指标 并将其添加到现有的分析报告和信息中心

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

使用自定义指标或事件

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

在分析工具中衡量自定义指标或事件 三个步骤：

  1. 定义或 注册 工具管理中的自定义指标（如果需要）。（注意：并非所有产品 分析服务提供商要求提前定义自定义指标。）
  2. 在前端 JavaScript 代码中计算指标的值。
  3. 将指标值发送到您的分析后端，并确保其名称或 ID 与第 1 步中定义的内容一致（再次强调，如果需要）。

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

以下代码示例展示了在 Google Cloud 中 代码并将其发送到分析服务。

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 的这种方法的一个示例。此 是开源的报告， 因此，开发者可以将其作为本单元介绍的技术示例 部分。

Web Vitals 的屏幕截图 举报

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

有些效果指标可以在页面加载完毕后计算 而其他代码（如 CLS）则会考虑网页的整个生命周期，并且仅 一旦页面开始卸载，就会产生最终的映像

不过，这可能会带来问题，因为 beforeunload 和 unload 事件不可靠（尤其是在移动设备上），并且 建议 （因为它们可能会阻止网页符合“往返”选项的要求） Cache）。

对于跟踪网页整个生命周期的指标，最好将任何 指标的当前值为 visibilitychange 事件期间，每当 页面的可见性状态更改为 hidden。这是因为，网页 可见性状态更改为 hidden，则无法保证任何脚本 这样该网页便可以再次运行。在移动操作系统上尤其如此 系统无需任何页面回调即可关闭浏览器应用本身 触发。

请注意，移动操作系统通常会触发 visibilitychange 事件。 他们在关闭标签页或导航到时也会触发 visibilitychange 事件 新页面。这使得 visibilitychange 事件比 unload 或 beforeunload 事件。

长期监控性能

更新 Google Analytics 实现方式以跟踪和报告 下一步是跟踪网站更改 对性能的影响

对更改进行版本控制

跟踪更改的一种简单（且最终不可靠）的方法是部署 然后假定在测试实施后收到的所有指标 部署日期与新网站以及 与旧网站保持一致。然而，考虑多种因素的 （包括在 HTTP、Service Worker 或 CDN 层进行缓存）可以防止 工作。

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

运行实验

您可以跟踪多个版本（或 实验）。

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

在数据分析中开展实验后，您可以发布 面向一部分用户进行实验性更改 并比较 对照组中用户表现的变化。完成 对更改确实能提升效果的信心，可以面向 所有用户。

确保衡量不会影响效果

在衡量针对真实用户的性能时，务必要确保 您正在运行的效果衡量代码不会对 网页性能如果是，那么你试图得出任何结论， 评估效果对业务的影响并不可靠，因为 永远不知道分析代码本身的存在 造成负面影响。

在 Kubernetes Engine 上部署 RUM 分析代码时， 正式版网站：

推迟分析

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

用于衡量 Core Web Vitals 指标的所有 API 都是 旨在支持异步和延迟的脚本加载（通过 buffered 标志），因此 因此你无需急于尽早加载脚本

如果您要衡量的指标稍后在 网页加载时间轴时，您应该仅内嵌需要提前运行的代码 并放入文档的 <head> 中（这样才不会造成阻碍呈现的内容） 请求）并推迟执行其余操作。不要加载所有 因为单个指标需要它，就尽早进行分析。

不要创建耗时较长的任务

运行 Google Analytics 代码通常会响应用户输入，但如果您的 Google Analytics 代码 执行大量 DOM 测量或使用其他处理器密集型 API 分析代码本身可能会导致输入响应不佳。此外，如果 包含您的分析代码的 JavaScript 文件很大，正在执行该文件 可能会阻塞主线程，并对页面的 Interaction to Next Paint (INP) 产生负面影响。

使用非阻塞 API

API，例如 sendBeacon() 和 requestIdleCallback() 专为运行非关键任务而设计， 阻止用户关键任务。

这些 API 是在 RUM 分析库中使用的出色工具。

一般而言，所有分析信标应使用 sendBeacon() API 发送 （如果有），并且所有被动分析衡量代码都应在 空闲时段。

只跟踪所需内容

浏览器公开了大量性能数据， 但不一定表示您就应该将其录制下来， 分析服务器。

例如，Resource Timing API 针对您网页上加载的每项资源提供详细的耗时数据。 然而，这些数据不太可能在销售领域中 提高资源加载性能。

简而言之，不要只跟踪数据就行了，还要确保数据将用于 然后再消耗资源对其进行跟踪