自定义指标

Philip Walton

拥有您可以普遍衡量的以用户为中心的指标非常重要。这些指标让您可以

  • 了解真实用户体验整个 Web 的情况。
  • 将您的网站与竞争对手的网站进行比较。
  • 在您的分析工具中跟踪实用且可操作的数据，而无需编写自定义代码。

通用指标提供了一个良好的基准，但在许多情况下，您需要衡量的不仅仅是这些指标，才能捕捉到您特定网站的完整体验。

自定义指标允许您衡量网站体验中可能仅适用于您网站的方面，例如

  • 单页应用 (SPA) 从一个“页面”过渡到另一个“页面”所需的时间。
  • 页面显示从数据库为登录用户获取的数据所需的时间。
  • 服务器端渲染 (SSR) 应用水合所需的时间。
  • 返回访客加载的资源的缓存命中率。
  • 游戏中的点击或键盘事件的事件延迟。

用于衡量自定义指标的 API

从历史上看，Web 开发者没有太多用于衡量性能的底层 API，因此他们不得不求助于一些技巧来衡量网站是否运行良好。

例如，可以通过运行 requestAnimationFrame 循环并计算每帧之间的增量来确定主线程是否因长时间运行的 JavaScript 任务而被阻塞。如果增量明显长于显示器的帧率，您可以将其报告为长任务。但是，不建议使用此类技巧，因为它们实际上会影响性能本身（例如，耗尽电池电量）。

有效性能衡量的首要原则是确保您的性能衡量技术本身不会导致性能问题。因此，对于您在网站上衡量的任何自定义指标，最好尽可能使用以下 API 之一。

Performance Observer API

浏览器支持

  • Chrome: 52.
  • Edge: 79.
  • Firefox: 57.
  • Safari: 11.

来源

Performance Observer API 是收集和显示此页面讨论的所有其他性能 API 数据的机制。理解它对于获得良好数据至关重要。

您可以使用 PerformanceObserver 被动地订阅与性能相关的事件。这使得 API 回调在空闲期间触发，这意味着它们通常不会干扰页面性能。

要创建 PerformanceObserver，请向其传递一个回调，以便在新性能条目分派时运行。然后，您可以使用 observe() 方法告知观察器要侦听哪些类型的条目

const po = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    // Log the entry and all associated details.
    console.log(entry.toJSON());
  }
});

po.observe({type: 'some-entry-type'});

以下部分列出了可用于观察的所有各种条目类型，但在较新的浏览器中，您可以通过静态 PerformanceObserver.supportedEntryTypes 属性检查哪些条目类型可用。

观察已发生的条目

默认情况下，PerformanceObserver 对象只能在条目发生时观察它们。如果您想延迟加载性能分析代码，使其不会阻止更高优先级的资源，这可能会导致问题。

要获取历史条目（在它们发生之后），请在调用 observe() 时将 buffered 标志设置为 true。浏览器将在首次调用 PerformanceObserver 回调时，从其 性能条目缓冲区 中包含历史条目，直到该类型的最大缓冲区大小。

po.observe({
  type: 'some-entry-type',
  buffered: true,
});

要避免使用的旧版性能 API

在 Performance Observer API 之前，开发者可以使用在 performance 对象上定义的以下三种方法访问性能条目

虽然这些 API 仍然受支持，但不建议使用它们，因为它们不允许您监听何时发出新条目。此外，许多新的 API（例如 largest-contentful-paint）不会通过 performance 对象公开，它们仅通过 PerformanceObserver 公开。

除非您特别需要与 Internet Explorer 兼容，否则最好在您的代码中避免使用这些方法，并向前使用 PerformanceObserver。

User Timing API

浏览器支持

  • Chrome: 28.
  • Edge: 12.
  • Firefox: 38.
  • Safari: 11.

来源

User Timing API 是一种用于基于时间的指标的通用衡量 API。它允许您任意标记时间点，然后在以后衡量这些标记之间的持续时间。

// Record the time immediately before running a task.
performance.mark('myTask:start');
await doMyTask();

// Record the time immediately after running a task.
performance.mark('myTask:end');

// Measure the delta between the start and end of the task
performance.measure('myTask', 'myTask:start', 'myTask:end');

虽然像 Date.now() 或 performance.now() 这样的 API 为您提供了类似的能力，但使用 User Timing API 的好处是它与性能工具很好地集成。例如，Chrome DevTools 在性能面板中可视化 User Timing 测量结果，许多分析提供商也会自动跟踪您进行的任何测量并将持续时间数据发送到他们的分析后端。

要报告 User Timing 测量结果，您可以使用 PerformanceObserver 并注册以观察 measure 类型的条目

// Create the performance observer.
const po = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    // Log the entry and all associated details.
    console.log(entry.toJSON());
  }
});

// Start listening for `measure` entries to be dispatched.
po.observe({type: 'measure', buffered: true});

Long Tasks API

浏览器支持

  • Chrome: 58.
  • Edge: 79.
  • Firefox：不支持。
  • Safari：不支持。

来源

Long Tasks API 对于了解浏览器的主线程何时被阻塞足够长的时间以影响帧率或输入延迟非常有用。该 API 将报告任何执行时间超过 50 毫秒的任务。

任何时候您需要运行开销大的代码，或者加载和执行大型脚本，跟踪该代码是否阻塞了主线程都很有用。事实上，许多更高级别的指标都是在 Long Tasks API 本身之上构建的（例如可交互时间 (TTI) 和 总阻塞时间 (TBT)）。

要确定何时发生长任务，您可以使用 PerformanceObserver 并注册以观察 longtask 类型的条目

// Create the performance observer.
const po = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    // Log the entry and all associated details.
    console.log(entry.toJSON());
  }
});

// Start listening for `longtask` entries to be dispatched.
po.observe({type: 'longtask', buffered: true});

Long Animation Frames API

浏览器支持

  • Chrome: 123.
  • Edge: 123.
  • Firefox：不支持。
  • Safari：不支持。

来源

Long Animation Frames API 是 Long Tasks API 的新迭代，它着眼于超过 50 毫秒的长帧，而不是长任务。这解决了 Long Tasks API 的一些缺点，包括更好的归因和更广泛的潜在问题延迟范围。

要确定何时发生长帧，您可以使用 PerformanceObserver 并注册以观察 long-animation-frame 类型的条目

// Create the performance observer.
const po = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    // Log the entry and all associated details.
    console.log(entry.toJSON());
  }
});

// Start listening for `long-animation-frame` entries to be dispatched.
po.observe({type: 'long-animation-frame', buffered: true});

Element Timing API

浏览器支持

  • Chrome: 77.
  • Edge: 79.
  • Firefox：不支持。
  • Safari：不支持。

来源

最大内容绘制 (LCP) 指标对于了解何时将最大的图像或文本块绘制到屏幕上非常有用，但在某些情况下，您希望衡量不同元素的渲染时间。

对于这些情况，请使用 Element Timing API。LCP API 实际上是在 Element Timing API 之上构建的，并添加了对最大内容元素的自动报告，但您也可以通过显式地向其他元素添加 elementtiming 属性，并注册 PerformanceObserver 以观察 element 条目类型来报告其他元素。

<img elementtiming="hero-image" />
<p elementtiming="important-paragraph">This is text I care about.</p>
<!-- ... -->

<script>
  const po = new PerformanceObserver((entryList) => {
    for (const entry of entryList.getEntries()) {
      // Log the entry and all associated details.
      console.log(entry.toJSON());
    }
  });

  // Start listening for `element` entries to be dispatched.
  po.observe({type: 'element', buffered: true});
</script>

Event Timing API

浏览器支持

  • Chrome: 76.
  • Edge: 79.
  • Firefox: 89.
  • Safari：不支持。

来源

交互到下次绘制 (INP) 指标通过观察页面生命周期中的所有点击、触摸和键盘交互来评估页面的整体响应速度。页面的 INP 通常是完成时间最长的交互，从用户发起交互时开始，到浏览器绘制下一个帧以显示用户输入的可视结果时结束。

INP 指标是通过 Event Timing API 实现的。此 API 公开了事件生命周期中发生的许多时间戳，包括

  • startTime：浏览器接收到事件的时间。
  • processingStart：浏览器能够开始处理事件的事件处理程序的时间。
  • processingEnd：浏览器完成执行从此事件的事件处理程序启动的所有同步代码的时间。
  • duration：从浏览器接收到事件到能够在完成执行从事件处理程序启动的所有同步代码后绘制下一帧的时间（出于安全原因，四舍五入到 8 毫秒）。

以下示例展示了如何使用这些值创建自定义测量结果

const po = new PerformanceObserver((entryList) => {
  // Get the last interaction observed:
  const entries = Array.from(entryList.getEntries()).forEach((entry) => {
    // Get various bits of interaction data:
    const inputDelay = entry.processingStart - entry.startTime;
    const processingTime = entry.processingEnd - entry.processingStart;
    const presentationDelay = entry.startTime + entry.duration - entry.processingEnd;
    const duration = entry.duration;
    const eventType = entry.name;
    const target = entry.target || "(not set)"

    console.log("----- INTERACTION -----");
    console.log(`Input delay (ms): ${inputDelay}`);
    console.log(`Event handler processing time (ms): ${processingTime}`);
    console.log(`Presentation delay (ms): ${presentationDelay}`);
    console.log(`Total event duration (ms): ${duration}`);
    console.log(`Event type: ${eventType}`);
    console.log(target);
  });
});

// A durationThreshold of 16ms is necessary to include more
// interactions, since the default is 104ms. The minimum
// durationThreshold is 16ms.
po.observe({type: 'event', buffered: true, durationThreshold: 16});

Resource Timing API

浏览器支持

  • Chrome: 29.
  • Edge: 12.
  • Firefox: 35.
  • Safari: 11.

来源

Resource Timing API 让开发者可以详细了解特定页面的资源是如何加载的。尽管 API 的名称如此，但它提供的信息不仅仅限于计时数据（尽管有大量此类数据）。您可以访问的其他数据包括

  • initiatorType：资源的获取方式：例如来自 <script> 或 <link> 标记，或者来自 fetch() 调用。
  • nextHopProtocol：用于获取资源的协议，例如 h2 或 quic。
  • encodedBodySize/decodedBodySize]：资源的大小，分别是其编码或解码形式
  • transferSize：实际通过网络传输的资源大小。当资源由缓存满足时，此值可能比 encodedBodySize 小得多，在某些情况下，它可以为零（如果不需要缓存重新验证）。

您可以使用资源计时条目的 transferSize 属性来衡量缓存命中率指标或缓存资源总大小指标，这有助于了解您的资源缓存策略如何影响回访用户的性能。

以下示例记录页面请求的所有资源，并指示每个资源是否由缓存满足。

// Create the performance observer.
const po = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    // If transferSize is 0, the resource was fulfilled using the cache.
    console.log(entry.name, entry.transferSize === 0);
  }
});

// Start listening for `resource` entries to be dispatched.
po.observe({type: 'resource', buffered: true});

浏览器支持

  • Chrome: 57.
  • Edge: 12.
  • Firefox: 58.
  • Safari: 15.

来源

Navigation Timing API 类似于 Resource Timing API，但它仅报告导航请求。navigation 条目类型也类似于 resource 条目类型，但它包含一些特定于导航请求的附加信息（例如 DOMContentLoaded 和 load 事件何时触发）。

许多开发者跟踪以了解服务器响应时间的指标 (首字节时间 (TTFB)) 可以使用 Navigation Timing API 获得 - 具体来说，它是条目的 responseStart 时间戳。

// Create the performance observer.
const po = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    // If transferSize is 0, the resource was fulfilled using the cache.
    console.log('Time to first byte', entry.responseStart);
  }
});

// Start listening for `navigation` entries to be dispatched.
po.observe({type: 'navigation', buffered: true});

使用 Service Worker 的开发者可能关心的另一个指标是导航请求的 Service Worker 启动时间。这是浏览器启动 Service Worker 线程所需的时间，然后才能开始拦截 fetch 事件。

特定导航请求的 Service Worker 启动时间可以从 entry.responseStart 和 entry.workerStart 之间的增量确定。

// Create the performance observer.
const po = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    console.log('Service Worker startup time:',
        entry.responseStart - entry.workerStart);
  }
});

// Start listening for `navigation` entries to be dispatched.
po.observe({type: 'navigation', buffered: true});

Server Timing API

浏览器支持

  • Chrome: 65.
  • Edge: 79.
  • Firefox: 61.
  • Safari: 16.4.

来源

Server Timing API 允许您通过响应标头将特定于请求的计时数据从服务器传递到浏览器。例如，您可以指示在数据库中查找特定请求的数据花费了多长时间 - 这对于调试由服务器速度缓慢引起的性能问题非常有用。

对于使用第三方分析提供商的开发者来说，Server Timing API 是将服务器性能数据与这些分析工具可能衡量的其他业务指标关联起来的唯一方法。

要在响应中指定服务器计时数据，您可以使用 Server-Timing 响应标头。这是一个示例。

HTTP/1.1 200 OK

Server-Timing: miss, db;dur=53, app;dur=47.2

然后，从您的页面中，您可以从 Resource Timing 和 Navigation Timing API 的 resource 或 navigation 条目中读取此数据。

// Create the performance observer.
const po = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    // Logs all server timing data for this response
    console.log('Server Timing', entry.serverTiming);
  }
});

// Start listening for `navigation` entries to be dispatched.
po.observe({type: 'navigation', buffered: true});