衡量离线使用情况
使用集合保持井井有条根据您的偏好保存内容并对其进行分类。

本文向您展示如何跟踪您网站的离线使用情况，以便您可以论证为什么您的网站需要更好的离线体验。

Stephan Giesau

Martin Schierle

本文向您展示如何跟踪您网站的离线使用情况，以帮助您论证为什么您的网站需要更好的离线模式。它还解释了在实施离线使用情况分析时要避免的缺陷和问题。

在线和离线浏览器事件的缺陷

跟踪离线使用情况的显而易见的解决方案是为 online 和 offline 事件（许多浏览器都支持）创建事件侦听器，并将您的分析跟踪逻辑放在这些侦听器中。不幸的是，这种方法存在一些问题和限制

一般来说，跟踪每个网络连接状态事件可能过度，并且在以隐私为中心的世界中适得其反，在这种世界中，应尽可能少地收集数据。此外，online 和 offline 事件可能会在网络丢失的瞬间触发，用户可能甚至看不到或注意不到。
离线活动的分析跟踪永远不会到达分析服务器，因为用户... 嗯，处于离线状态。
当用户离线时，本地跟踪时间戳，并在用户重新上线时将离线活动发送到分析服务器，这取决于用户是否重新访问您的网站。如果用户由于缺少离线模式而离开您的网站并且永远不再访问，您将无法跟踪该情况。跟踪离线跳出率的能力对于论证为什么您的网站需要更好的离线模式至关重要的数据。
online 事件不是很可靠，因为它仅了解网络访问，而不了解互联网访问。因此，用户可能仍然处于离线状态，并且发送跟踪 ping 仍然可能失败。
即使在离线状态下用户仍然停留在当前页面上，也不会跟踪任何其他分析事件（例如，滚动事件、点击等），这可能是更相关和有用的信息。
一般来说，离线本身也不是太有意义。作为网站开发人员，了解哪些类型的资源加载失败可能更重要。这在 SPA 的上下文中尤其相关，在 SPA 中，网络连接断开可能不会导致浏览器离线错误页面（用户可以理解），但更可能导致页面的随机动态部分静默失败。

您仍然可以使用此解决方案来基本了解离线使用情况，但需要仔细考虑许多缺点和限制。

更好的方法：Service Worker

启用离线模式的解决方案最终成为跟踪离线使用情况的更好解决方案。基本思想是将分析 ping 存储到 IndexedDB 中，只要用户处于离线状态，并在用户再次上线时重新发送它们。对于 Google Analytics，这已经可以通过 Workbox 模块现成可用，但请记住，延迟超过四小时发送的命中可能不会被处理。在其最简单的形式中，它可以在基于 Workbox 的 Service Worker 中通过以下两行代码激活

import * as googleAnalytics from 'workbox-google-analytics';

googleAnalytics.initialize();

这会跟踪离线状态下的所有现有事件和页面浏览 ping，但您不会知道它们是离线发生的（因为它们只是按原样重播）。为此，您可以使用 Workbox 操作跟踪请求，方法是将 offline 标志添加到分析 ping，使用自定义维度（以下代码示例中的 cd1）

import * as googleAnalytics from 'workbox-google-analytics';

googleAnalytics.initialize({
  parameterOverrides: {
    cd1: 'offline',
  },
});

如果用户在互联网连接恢复之前由于离线而退出页面怎么办？即使这通常会使 Service Worker 进入休眠状态（因为它在连接恢复时无法发送数据），Workbox Google Analytics 模块也使用 Background Sync API，这会在连接恢复后稍后发送分析数据，即使在用户关闭选项卡或浏览器的情况下也是如此。

仍然存在一个缺点：虽然这使现有跟踪具有离线功能，但在您实施基本离线模式之前，您很可能看不到太多相关数据传入。当连接断开时，用户仍然会快速离开您的网站。但现在您至少可以通过比较应用了离线维度的用户与普通用户的平均会话时长和用户互动来衡量和量化这一点。

SPA 和延迟加载

如果访问构建为多页网站的页面的用户离线并尝试导航，则会显示浏览器的默认离线页面，帮助用户了解正在发生的事情。但是，构建为单页应用程序的页面工作方式不同。用户停留在同一页面上，并且通过 AJAX 动态加载新内容，而无需任何浏览器导航。用户在离线时看不到浏览器错误页面。相反，页面的动态部分呈现错误，进入未定义状态，或者只是停止动态。

由于延迟加载，多页网站中也可能发生类似的效果。例如，可能初始加载是在线发生的，但用户在滚动之前离线了。折叠下方的所有延迟加载内容都将静默失败并丢失。

由于这些情况确实让用户感到恼火，因此跟踪它们是有意义的。Service Worker 是捕获网络错误的理想场所，并最终使用分析来跟踪它们。使用 Workbox，可以配置全局捕获处理程序，通过发送消息事件来通知页面有关失败的请求

import { setCatchHandler } from 'workbox-routing';

setCatchHandler(({ event }) => {
  // https://mdn.org.cn/docs/Web/API/Client/postMessage
  event.waitUntil(async function () {
    // Exit early if we don't have access to the client.
    // Eg, if it's cross-origin.
    if (!event.clientId) return;

    // Get the client.
    const client = await clients.get(event.clientId);
    // Exit early if we don't get the client.
    // Eg, if it closed.
    if (!client) return;

    // Send a message to the client.
    client.postMessage({
      action: "network_fail",
      url: event.request.url,
      destination: event.request.destination
    });

    return Response.error();

  }());
});

与其侦听所有失败的请求，另一种方法是仅捕获特定路由上的错误。例如，如果我们想报告发生在 /products/* 路由上的错误，我们可以在 setCatchHandler 中添加一个检查，该检查使用正则表达式过滤 URI。更简洁的解决方案是使用自定义处理程序实现 registerRoute。这会将业务逻辑封装到单独的路由中，从而在更复杂的 Service Worker 中具有更好的可维护性

import { registerRoute } from 'workbox-routing';
import { NetworkOnly } from 'workbox-strategies';

const networkOnly = new NetworkOnly();
registerRoute(
  new RegExp('https:\/\/example\.com\/products\/.+'),
  async (params) => {
    try {
      // Attempt a network request.
      return await networkOnly.handle(params);
    } catch (error) {
      // If it fails, report the error.
      const event = params.event;
      if (!event.clientId) return;
      const client = await clients.get(event.clientId);
      if (!client) return;

      client.postMessage({
        action: "network_fail",
        url: event.request.url,
        destination: "products"
      });

      return Response.error();
    }
  }
);

作为最后一步，页面需要侦听 message 事件，并发送分析 ping。同样，请确保缓冲在 Service Worker 中发生的离线分析请求。如前所述，初始化 workbox-google-analytics 插件以获得内置的 Google Analytics 支持。

以下示例使用 Google Analytics，但可以以相同的方式应用于其他分析供应商。

if ("serviceWorker" in navigator) {
  // ... SW registration here

  // track offline error events
  navigator.serviceWorker.addEventListener("message", event => {
    if (gtag && event.data && event.data.action === "network_fail") {
      gtag("event", "network_fail", {
        event_category: event.data.destination,
        // event_label: event.data.url,
        // value: event.data.value
      });
    }
  });
}

这将跟踪 Google Analytics 中失败的资源加载，可以在其中使用报告对其进行分析。导出的见解可用于改进 Service Worker 缓存和一般错误处理，以使页面在不稳定的网络条件下更健壮和可靠。

后续步骤

本文介绍了跟踪离线使用情况的不同方法及其优点和缺点。虽然这可以帮助量化有多少用户离线并因此遇到问题，但这仍然只是一个开始。只要您的网站不提供构建良好的离线模式，您显然不会在分析中看到太多离线使用情况。

我们建议先全面实施跟踪，然后迭代扩展您的离线功能，同时关注跟踪数字。首先从简单的离线错误页面开始——使用 Workbox 可以轻松完成——并且应该被认为是 UX 最佳实践，类似于自定义 404 页面。然后逐步转向更高级的离线回退，最后转向真正的离线内容。确保向您的用户充分宣传和解释这一点，您将看到使用量增加。毕竟，每个人都会时不时地离线。

查看如何报告指标并建立性能文化和跨职能地解决网站速度问题，以获取有关说服跨职能利益相关者在您的网站上投入更多资金的技巧。尽管这些帖子侧重于性能，但它们应该可以帮助您获得关于如何与利益相关者互动的总体思路。

英雄照片由 JC Gellidon 在 Unsplash 上拍摄。

衡量离线使用情况 使用集合保持井井有条 根据您的偏好保存内容并对其进行分类。

在线和离线浏览器事件的缺陷

更好的方法：Service Worker

SPA 和延迟加载

后续步骤

衡量离线使用情况
使用集合保持井井有条根据您的偏好保存内容并对其进行分类。