在现场调试性能

了解如何使用调试信息对性能数据进行归因 ,帮助您通过 Google Analytics 识别并解决用户实际遇到的问题

Google 提供了两类用于衡量和调试性能的工具:

现场工具提供的数据更为准确,这些数据 实验工具通常能更好地帮助您发现和修复问题, 问题。

CrUX 数据更能代表网页的实际性能, CrUX 得分可能无法帮您弄清楚如何提高自己的 性能

另一方面,Lighthouse 会发现问题 并提供改进建议。不过,Lighthouse 仅会 以检查在网页加载时发现的性能问题。没有检测到问题 仅在用户进行滚动或点击等互动后才会展示 按钮。

这就引出了一个重要的问题:如何为广告系列捕获调试信息 Core Web Vitals 还是实际用户的其他性能指标?

本文将详细介绍您可以使用哪些 API 收集 每个当前 Core Web Vitals 指标的调试信息,并给出 为您提供有关如何在现有分析工具中捕获这些数据的提示。

用于归因和调试的 API

Cumulative Layout Shift (CLS)

在所有 Core Web Vitals 指标中,CLS 或许是 在现场收集调试信息是最重要的。衡量的是 CLS 也就是在网页的整个生命周期内 例如,用户滚动了多远、点击的内容,等等。 对是否存在布局偏移以及哪些元素发生了偏移的影响。

请参考以下来自 PageSpeed Insights 的报告:

<ph type="x-smartling-placeholder">
</ph> 采用不同 CLS 值的 PageSpeed Insights 报告
PageSpeed Insights 会同时显示实测数据和实验室数据(如果有),但这些数据可能会有所不同

实验室 (Lighthouse) 报告的 CLS 值与来自 字段(CrUX 数据)截然不同,如果您考虑到 该网页可能会包含大量互动内容 在 Lighthouse 中测试时未使用。

但即使您知道用户互动会影响实测数据,也仍然需要 需要知道网页上的哪些元素发生偏移,从而得到 0.28 的得分 为第 75 百分位。LayoutShiftAttribution 让这一切成为可能

获取布局偏移归因

LayoutShiftAttribution 每个 layout-shift 条目都会公开布局不稳定性 API 发出相应命令。

有关这两个界面的详细说明,请参阅调试布局 Shifts。为了 在这篇博文中,您需要知道的主要是,作为开发者, 来观察网页上发生的每次布局偏移,以及哪些元素 不断转变。

下面是一些示例代码,它记录了每次布局偏移以及 变化:

new PerformanceObserver((list) => {
  for (const {value, startTime, sources} of list.getEntries()) {
    // Log the shift amount and other entry info.
    console.log('Layout shift:', {value, startTime});
    if (sources) {
      for (const {node, curRect, prevRect} of sources) {
        // Log the elements that shifted.
        console.log('  Shift source:', node, {curRect, prevRect});
      }
    }
  }
}).observe({type: 'layout-shift', buffered: true});

出于优化目的,测量数据并将其发送到分析工具并不现实 发生的每一次布局偏移不过,通过监控所有班次,您可以 可以跟踪最坏的情况,并仅报告有关这些情况的信息。

这样做的目的不是找出并解决每次应用布局偏移 每位用户目标是确定影响最大数量的 用户,因此对网页 CLS 的贡献最大(在第 75 个百分位)。

此外,您不需要在每次有事件发生时都计算最大的源元素 Shift,则只有在准备好将 CLS 值发送到 Google Analytics 工具。

以下代码接受一个 layout-shift 条目的列表,这些条目 更改为 CLS,并返回最大偏移的最大源元素:

function getCLSDebugTarget(entries) {
  const largestEntry = entries.reduce((a, b) => {
    return a && a.value > b.value ? a : b;
  });
  if (largestEntry && largestEntry.sources && largestEntry.sources.length) {
    const largestSource = largestEntry.sources.reduce((a, b) => {
      return a.node && a.previousRect.width * a.previousRect.height >
          b.previousRect.width * b.previousRect.height ? a : b;
    });
    if (largestSource) {
      return largestSource.node;
    }
  }
}

在确定了产生最大转变的最大元素后, 您可以向分析工具报告这一情况

对于给定网页,对 CLS 影响最大的元素很有可能从 但如果您将这些元素汇总到所有用户中, 生成影响最多用户的转变元素列表。

在确定并解决造成这些流量变化的根本原因之后, 元素,您的分析代码就会开始将较小的变化报告为“最差” 出现哪些变化最终,所报告的所有变化都会很小,以至于 您的网页排名在“良好”阈值 0.1

可能有助于捕获的一些其他元数据以及最大规模的变动 source 元素是:

  • 发生最大转变的时间
  • 发生最大偏移时的网址路径(适用于动态 更新网址,例如单页应用)。

Largest Contentful Paint (LCP)

若要在实际运行中调试 LCP,您需要的主要信息是 元素是该特定元素的最大元素(LCP 候选元素) 网页加载时间。

请注意,LCP 完全有可能(实际上相当常见) 候选元素会因用户而异,即使对于同一个 页面。

以下是可能导致此问题的原因:

  • 用户设备具有不同的屏幕分辨率,这导致不同的 页面布局,从而在视口内显示不同的元素。
  • 用户并不总是加载滚动到最顶部的页面。链接常常 包含 Fragment 标识符,甚至是 文本片段,这意味着 使网页能够在页面上任意滚动位置加载并显示。
  • 内容可能是针对当前用户的个性化内容,因此 LCP 候选元素 可能因用户而异。

也就是说,您不能对哪个元素或哪组元素做出假设 将是特定网页中最常见的 LCP 候选元素。您必须 根据真实用户行为来衡量效果

确定 LCP 候选元素

要在 JavaScript 中确定 LCP 候选元素,您可以使用 Largest Contentful Paint API 用于确定 LCP 时间值的 API。

在观察 largest-contentful-paint 条目时,您可以确定 查看上一个条目的 element 属性,了解当前 LCP 候选元素:

new PerformanceObserver((list) => {
  const entries = list.getEntries();
  const lastEntry = entries[entries.length - 1];

  console.log('LCP element:', lastEntry.element);
}).observe({type: 'largest-contentful-paint', buffered: true});

知道 LCP 候选元素后,您可以将其发送到您的分析工具 以及指标值与 CLS 一样 最重要因素。

除了 LCP 候选元素之外, LCP 子部分时间,这非常有用 以确定与您的网站相关的具体优化步骤。

Interaction to Next Paint (INP)

在 INP 字段中捕获的最重要的信息包括:

  1. 用户与哪个元素进行了互动
  2. 为什么是这种互动类型
  3. 互动发生的时间

导致交互缓慢的主要原因是主线程阻塞, 经常出现这种错误。知道大多数慢交互是否 有助于确定需要修正的问题 问题。

INP 指标会考虑 包括以何种方式运行任何已注册事件监听器 以及在完成所有事件监听器后绘制下一帧所需的时间 。也就是说,对于 INP 而言 哪些元素往往会导致交互速度缓慢, 它们分别是

以下代码会记录 INP 条目的目标元素和时间。

function logINPDebugInfo(inpEntry) {
  console.log('INP target element:', inpEntry.target);
  console.log('INP interaction type:', inpEntry.name);
  console.log('INP time:', inpEntry.startTime);
}

请注意,此代码并未显示如何确定哪个 event 条目是 INP 因为这个逻辑更复杂不过,下一部分将详细介绍 如何使用 web-vitals JavaScript 库。

Web-Vitals JavaScript 库的使用

前面部分提供了一些常规建议和用于捕获 要添加到发送到分析工具的数据中的调试信息。

从版本 3 开始,web-vitals JavaScript 库包含提供方说明 构建 会显示所有这些信息,另外还会提供一些 信号

以下代码示例展示了如何设置一个额外的事件 参数(或自定义 维度),其中包含 有助于确定性能根本原因的调试字符串 问题。

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

function sendToGoogleAnalytics({name, value, id, attribution}) {
  const eventParams = {
    metric_value: value,
    metric_id: id,
  }

  switch (name) {
    case 'CLS':
      eventParams.debug_target = attribution.largestShiftTarget;
      break;
    case 'LCP':
      eventParams.debug_target = attribution.element;
      break;
    case 'INP':
      eventParams.debug_target = attribution.interactionTarget;
      break;
  }

  // Assumes the global `gtag()` function exists, see:
  // https://developers.google.com/analytics/devguides/collection/ga4
  gtag('event', name, eventParams);
}

onCLS(sendToGoogleAnalytics);
onLCP(sendToGoogleAnalytics);
onFID(sendToGoogleAnalytics);
onINP(sendToGoogleAnalytics);

这段代码是 Google Analytics 专用的,但大体上解释的 其他分析工具

此代码也仅显示了如何报告单个调试信号,但它是 能够针对每个渠道收集和报告多种不同信号 指标。

例如,如需调试 INP,您可能需要收集 互动类型、时间、loadState、 阶段等(例如长动画帧数据)。

web-vitals 归因 build 会显示额外的归因信息, 如以下 INP 示例所示:

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

function sendToGoogleAnalytics({name, value, id, attribution}) {
  const eventParams = {
    metric_value: value,
    metric_id: id,
  }

  switch (name) {
    case 'INP':
      eventParams.debug_target = attribution.interactionTarget;
      eventParams.debug_type = attribution.interactionType;
      eventParams.debug_time = attribution.interactionTime;
      eventParams.debug_load_state = attribution.loadState;
      eventParams.debug_interaction_delay = Math.round(attribution.inputDelay);
      eventParams.debug_processing_duration = Math.round(attribution.processingDuration);
      eventParams.debug_presentation_delay =  Math.round(attribution.presentationDelay);
      break;

    // Additional metric logic...
  }

  // Assumes the global `gtag()` function exists, see:
  // https://developers.google.com/analytics/devguides/collection/ga4
  gtag('event', name, eventParams);
}

onCLS(sendToGoogleAnalytics);
onLCP(sendToGoogleAnalytics);
onFID(sendToGoogleAnalytics);
onINP(sendToGoogleAnalytics);

请参阅网页指标归因 文档 显示的调试信号的完整列表。

报告并直观呈现数据

开始收集调试信息以及指标值后, 下一步就是汇总所有用户的数据,以便开始查找 模式和趋势。

如前所述,您不一定需要解决所有问题 您需要解决用户遇到的问题(尤其是在最初阶段), 影响最多的用户,这也应该是问题所在 对 Core Web Vitals 得分影响最大的项目。

对于 GA4,请参阅介绍如何使用 BigQuery

摘要

希望这篇帖子能够帮助您概述使用 现有的性能 API 和 web-vitals 库,用于获取调试信息 帮助根据现场实际用户访问情况来诊断广告效果。虽然 指南重点介绍 Core Web Vitals,这些概念也适用于调试 任何可在 JavaScript 中衡量的性能指标

如果您刚开始衡量效果,并且已经 如果您是 Google Analytics 用户,不妨从网页指标报告工具入手 因为它已支持为核心网页报告调试信息 Vitals 指标。

如果您是分析服务供应商,希望改进自己的产品和 向用户提供更多调试信息,不妨考虑使用 此处介绍的技巧,但不要局限于我们提出的观点 此处。本博文主要面向所有分析工具; 然而,各个分析工具可能(并且应该)捕获和报告 提供了更多调试信息

最后,如果您认为由于以下原因,您在调试这些指标的能力上存在问题 如果 API 本身缺少功能或信息,我们会将您的反馈发送给 web-vitals-feedback@googlegroups.com.