此页面由 Cloud Translation API 翻译。

衡量离线使用情况

如何跟踪网站的离线使用情况，以便阐明您的网站为何需要更好的离线体验。

Stephan Giesau

Martin Schierle

本文将向您介绍如何跟踪网站的离线使用情况，以帮助您了解网站需要更好的离线模式。还说明了在实施代码时要避免的陷阱和问题离线使用情况分析

在线和离线浏览器事件的误区

跟踪离线使用情况显而易见的解决方案是为 online和 offline 事件（许多浏览器支持），并将您的分析数据跟踪逻辑。遗憾的是，这种方法存在一些问题和限制方法：

一般来说，跟踪每个网络连接状态事件可能过多，在以隐私保护为中心的时代，应尽可能少用数据，会适得其反。此外，online 和 offline 事件可能会在网络丢失，用户可能根本看不到或注意到这一点。
对线下活动的分析跟踪永远无法到达分析服务器，因为用户处于离线状态
当用户离线时在本地跟踪时间戳，并将离线活动发送到分析服务器在用户恢复在线状态时取决于该用户再次访问您的网站。如果用户由于缺少离线模式而离开您的网站且从未重新访问，那么您没办法跟踪跟踪线下访问者流失情况对于构建网站需要更好的离线模式的案例。
online 事件不是很可靠，因为它只知道网络访问，而不是互联网访问。因此，用户可能仍然处于离线状态，且发送跟踪 ping 可以也仍然会失败
即使用户处于离线状态时仍然停留在当前页面上， Google Analytics 事件（例如滚动事件、点击等）也会被跟踪，相关而实用的信息
离线本身通常也没什么意义。作为网站开发者更重要的是要知道哪些类型的资源会加载失败。这与在 SPA 中，网络连接断开可能不会导致浏览器离线错误网页（用户能理解），但更有可能随机显示网页的随机动态部分失败无声地。

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

更好的方法：Service Worker

事实证明，启用离线模式的解决方案是更好的离线跟踪解决方案。其基本思路是，只要用户处于离线状态，系统就会将分析 ping 存储到 IndexedDB 中，并在用户重新联网时重新发送这些邮件对于 Google Analytics，我们已经提供现成可用的工作区，但请注意，发送的匹配数推迟了 4 小时可能无法得到处理。形式最简单的服务可以在基于 Workbox 的服务中激活 worker：

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

googleAnalytics.initialize();

这样就能在离线状态下跟踪所有现有事件和网页浏览 ping，但您不会知道它们是离线发生的（因为它们只是按原样重放）。为此您可以使用 Workbox 方法是使用自定义维度（代码中的 cd1）向分析 ping 添加 offline 标记。示例如下）：

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

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

如果用户由于离线而离开页面，而未连接互联网，该怎么办？返回？尽管这通常会使 Service Worker 进入休眠状态（因为它无法发送数据重新连接时），Workbox Google Analytics 模块将使用后台同步 API：将分析数据发送到数据，即使用户关闭标签页或浏览器也是如此。

但这也有一个缺点：虽然这使得现有跟踪能够离线进行，但您最有可能您只有在实现基本离线模式后才能看到传入的相关数据。用户仍然会在连接中断时迅速离开您的网站。但现在，您至少可以测量量化衡量方式，方法是比较离线用户的平均会话时长和用户互动度与常规用户进行比较

SPA 和延迟加载

如果用户访问某个采用多页网站形式的网页，但在离线状态下尝试进行浏览，那么浏览器的系统会显示默认的离线页面，帮助用户了解所发生的情况。然而，构建为单页应用的工作方式有所不同用户未离开页面，又看到新内容通过 AJAX 动态加载，无需进行任何浏览器导航。用户看不到浏览器错误页面。相反，网页的动态部分会呈现存在错误的内容，或停止动态化。

在多页网站中，也可能会因延迟加载而产生类似的效果。例如，初始加载是在线进行的，但用户在滚动之前就下线了。所有延迟加载的内容非首屏将会失效且缺失。

因为这些情况会让用户感到非常烦恼，因此跟踪它们是明智之举。Service Worker 是发现网络错误并最终通过分析工具跟踪错误的绝佳位置。有了 Workbox，全局捕获处理程序可配置为通过发送消息事件通知网页失败的请求：

import { setCatchHandler } from 'workbox-routing';

setCatchHandler(({ event }) => {
  // https://developer.mozilla.org/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 中离线发生的分析请求。如请初始化内置 Google Analytics 的 workbox-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 缓存和错误处理，使页面更可靠在网络条件不稳定的情况下仍然非常可靠。

后续步骤

本文介绍了跟踪离线使用情况的不同方法及其优缺点。虽然这有助于量化您有多少用户由于离线而遇到问题，这仍然仅仅是一个开始只要您的网站未提供完善的离线模式显然在分析中，离线使用的情况不多

我们建议实施全面的跟踪，然后在关注跟踪编号。先从简单的离线错误页面开始 - 使用只需简单操作，正确做法都应该被视为类似于自定义 404 网页的用户体验最佳做法。然后，按自己的方式工作向更高级的线下后备广告最后才是真正的离线内容。确保投放广告并向用户说明这一点而且您会发现使用量也在不断增加。毕竟，每个人都会偶尔处于离线状态。

请参阅如何报告指标并打造效果文化和跨部门修复网站速度一文，了解相关技巧说服跨职能利益相关方对您的网站投入更多资金。虽然这些帖子注重效果，应该可以帮助您大致了解应该如何吸引相关方。

主打照片，由 JC Gellidon 在 Unsplash 用户上传。