此页面由 Cloud Translation API 翻译。

在现场调试性能

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

Philip Walton

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

实验室工具：Lighthouse 等工具，在此类工具中，网页加载模拟环境（例如，和低端移动设备）。
现场工具：Chrome 用户体验等工具报告 (CrUX)：根据来自 Chrome 的汇总真实用户数据。（请注意， PageSpeed 等工具报告的现场数据数据分析和搜索控制台数据来源 CrUX 数据。）

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

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

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

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

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

用于归因和调试的 API

Cumulative Layout Shift (CLS)

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

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

采用不同 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 字段中捕获的最重要的信息包括：

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

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

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。