Diese Seite wurde von der Cloud Translation API übersetzt.

Offlinenutzung messen

So erfassen Sie die Offlinenutzung Ihrer Website, um zu begründen, warum Ihre Website eine bessere Offlinenutzung benötigt.

Stephan Giesau

Martin Schierle

In diesem Artikel erfahren Sie, wie Sie die Offlinenutzung Ihrer Website erfassen, um zu begründen, warum Ihre Website einen besseren Offlinemodus benötigt. Außerdem werden Fallstricke und Probleme erläutert, die bei der Implementierung von Analysen zur Offlinenutzung vermieden werden sollten.

Die Fallstricke der Online- und Offline-Browserereignisse

Die naheliegende Lösung für das Tracking der Offlinenutzung besteht darin, Ereignis-Listener für die Ereignisse online und offline zu erstellen (die von vielen Browsern unterstützt werden) und die Analyse-Tracking-Logik in diese Listener einzubinden. Leider gibt es bei diesem Ansatz mehrere Probleme und Einschränkungen:

Im Allgemeinen ist es möglicherweise übertrieben, jedes Ereignis zum Netzwerkverbindungsstatus zu erfassen. Außerdem ist es in einer datenschutzorientierten Welt, in der so wenig Daten wie möglich erhoben werden sollten, kontraproduktiv. Außerdem können die Ereignisse online und offline bei nur einem kurzen Netzwerkausfall ausgelöst werden, den ein Nutzer wahrscheinlich nicht einmal bemerkt.
Das Analyse-Tracking der Offline-Aktivität würde den Analyseserver nie erreichen, da der Benutzer... nun ja, offline ist.
Wenn ein Zeitstempel lokal verfolgt wird, wenn ein Nutzer offline geht, und die Offlineaktivität an den Analyseserver zu senden, wenn er wieder online ist, hängt es davon ab, dass der Nutzer Ihre Website erneut besucht. Wenn der Nutzer Ihre Website aufgrund des fehlenden Offlinemodus verlässt und nie wiederkehrt, können Sie das nicht erfassen. Die Möglichkeit, Offline-Ausstiege zu erfassen, ist eine wichtige Information, um zu begründen, warum Ihre Website einen besseren Offlinemodus benötigt.
Das Ereignis online ist nicht sehr zuverlässig, da es nur den Netzwerkzugriff, nicht aber den Internetzugriff kennt. Daher kann ein Nutzer möglicherweise immer noch offline sein und das Senden des Tracking-Pings kann weiterhin fehlschlagen.
Auch wenn der Nutzer offline auf der aktuellen Seite bleibt, werden keine anderen Analyseereignisse (z.B. Scroll-Ereignisse oder Klicks) erfasst. Das sind möglicherweise die relevantesten und nützlichsten Informationen.
Auch das Offline-Sein an sich ist im Allgemeinen nicht sehr aussagekräftig. Als Websiteentwickler ist es möglicherweise wichtiger zu wissen, welche Arten von Ressourcen nicht geladen werden konnten. Dies ist besonders relevant im Zusammenhang mit SPAs, bei denen eine unterbrochene Netzwerkverbindung nicht zu einer Offlinefehlerseite des Browsers führt (die Nutzer verstehen), sondern eher zu einer stillen Fehlfunktion zufälliger dynamischer Seitenteile.

Sie können diese Lösung zwar verwenden, um sich ein grundlegendes Bild von der Offlinenutzung zu machen, aber die vielen Nachteile und Einschränkungen müssen sorgfältig berücksichtigt werden.

Ein besserer Ansatz: der Service Worker

Die Lösung, die den Offlinemodus aktiviert, eignet sich am besten für die Erfassung der Offlinenutzung. Analytics-Pings werden so lange in IndexedDB gespeichert, wie der Nutzer offline ist, und erst dann noch einmal gesendet, wenn er wieder online ist. Für Google Analytics ist diese Funktion bereits über ein Workbox-Modul verfügbar. Beachten Sie jedoch, dass Treffer, die mit einer Verzögerung von mehr als vier Stunden gesendet werden, möglicherweise nicht verarbeitet werden. In der einfachsten Form kann sie mit diesen beiden Zeilen in einem Workbox-basierten Dienst-Worker aktiviert werden:

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

googleAnalytics.initialize();

Damit werden alle vorhandenen Ereignisse und Seitenaufruf-Pings erfasst, während sie offline sind. Sie wissen jedoch nicht, dass sie offline stattgefunden haben, da sie einfach unverändert wiedergegeben werden. Dazu können Sie Tracking-Anfragen mit Workbox bearbeiten, indem Sie dem Analyse-Ping ein offline-Flag hinzufügen. Verwenden Sie dazu eine benutzerdefinierte Dimension (cd1 im Codebeispiel unten):

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

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

Was passiert, wenn der Nutzer die Seite verlässt, weil er offline ist, bevor eine Internetverbindung wiederhergestellt wird? Normalerweise wird der Dienst-Worker in diesem Fall in den Ruhemodus versetzt, da er die Daten nicht senden kann, wenn die Verbindung wiederhergestellt wird. Das Google Analytics-Modul von Workbox verwendet jedoch die Background Sync API, über die die Analysedaten später gesendet werden, wenn die Verbindung wiederhergestellt wird, auch wenn der Nutzer den Tab oder Browser schließt.

Es gibt immer noch einen Nachteil: Dadurch wird zwar das bestehende Tracking offline möglich, es werden jedoch wahrscheinlich nicht viele relevante Daten eingehen, wenn Sie einen einfachen Offlinemodus implementieren. Nutzer würden Ihre Website trotzdem schnell verlassen, wenn die Verbindung unterbrochen wird. Jetzt können Sie das zumindest messen und quantifizieren, indem Sie die durchschnittliche Sitzungsdauer und das Nutzer-Engagement für Nutzer mit der Dimension „offline“ mit Ihren regulären Nutzern vergleichen.

SPAs und Lazy Loading

Wenn Nutzer, die eine Seite besuchen, die als mehrseitige Website erstellt wurde, offline gehen und versuchen, sich zu bewegen, wird die Standard-Offlineseite des Browsers angezeigt, damit Nutzer verstehen, was passiert. Seiten, die als Single-Page-Anwendungen erstellt wurden, funktionieren jedoch anders. Der Nutzer bleibt auf derselben Seite und neuer Content wird dynamisch und ohne Browsernavigation über AJAX geladen. Nutzern wird die Fehlerseite nicht angezeigt, wenn sie offline gehen. Stattdessen werden die dynamischen Teile der Seite mit Fehlern gerendert, gehen in nicht definierte Status über oder sind einfach nicht mehr dynamisch.

Ähnliche Effekte können auf Websites mit mehreren Seiten aufgrund von Lazy Loading auftreten. Das kann zum Beispiel der Fall sein, wenn der anfängliche Ladevorgang online erfolgt ist, der Nutzer aber vor dem Scrollen offline gegangen ist. Alle Lazy-Load-Inhalte unterhalb des Folds werden nicht geladen und fehlen.

Da diese Fälle die Nutzer sehr stören, ist es sinnvoll, sie zu beobachten. Service Worker sind die perfekte Lösung, um Netzwerkfehler zu erkennen und mithilfe von Analysen zu verfolgen. Mit Workbox kann ein globaler Catch-Handler konfiguriert werden, um die Seite durch Senden eines Nachrichtenereignisses über fehlgeschlagene Anfragen zu informieren:

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();

  }());
});

Anstatt alle fehlgeschlagenen Anfragen zu überwachen, können Sie auch nur Fehler bei bestimmten Routen erfassen. Wenn wir beispielsweise nur Fehler bei Routen zu /products/* melden möchten, können wir in setCatchHandler eine Prüfung hinzufügen, die den URI mit einem regulären Ausdruck filtert. Eine elegantere Lösung besteht darin, registerRoute mit einem benutzerdefinierten Handler zu implementieren. Dadurch wird die Geschäftslogik in einer separaten Route kapselt, was die Verwaltbarkeit in komplexeren Service Workern verbessert:

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();
    }
  }
);

Als letzten Schritt muss die Seite das message-Ereignis abhören und den Analytics-Ping senden. Denken Sie daran, Analyseanfragen, die offline im Dienstarbeiter stattfinden, zu puffern. Initialisieren Sie wie zuvor beschrieben das workbox-google-analytics-Plug-in für die integrierte Google Analytics-Unterstützung.

Im folgenden Beispiel wird Google Analytics verwendet, es kann aber genauso für andere Analyseanbieter angewendet werden.

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
      });
    }
  });
}

So werden fehlgeschlagene Ressourcenladungen in Google Analytics erfasst und können in Berichten analysiert werden. Die gewonnenen Informationen können verwendet werden, um das Caching und die Fehlerbehandlung von Service Workern im Allgemeinen zu verbessern und die Seite bei instabilen Netzwerkbedingungen robuster und zuverlässiger zu machen.

Nächste Schritte

In diesem Artikel wurden verschiedene Möglichkeiten zum Erfassen der Offlinenutzung mit ihren Vor- und Nachteilen vorgestellt. So lässt sich zwar quantifizieren, wie viele Nutzer offline gehen und dadurch Probleme auftreten, aber das ist erst der Anfang. Solange Ihre Website keinen gut funktionierenden Offlinemodus bietet, werden in Analytics nicht viele Offlinenutzungen erfasst.

Wir empfehlen, das vollständige Tracking einzurichten und dann Ihre Offlinefunktionen in Iterationen mit Blick auf die Tracking-Zahlen zu erweitern. Beginnen Sie mit einer einfachen Offline-Fehlerseite – mit Workbox ist das ganz einfach – und sollten ohnehin als Best Practice für die Nutzererfahrung gelten, die benutzerdefinierten 404-Seiten ähnelt. Dann können Sie sich an erweiterte Offline-Fallbacks und schließlich an echte Offlineinhalte herantasten. Wenn Sie Ihre Nutzer gut darüber informieren und die Funktion bewerben, wird die Nutzung zunehmen. Schließlich ist jeder hin und wieder offline.

Unter Messwerte erfassen und eine Leistungskultur schaffen und Websitegeschwindigkeit funktionsübergreifend beheben finden Sie Tipps dazu, wie Sie funktionsübergreifende Stakeholder davon überzeugen können, mehr in Ihre Website zu investieren. Obwohl sich diese Beiträge auf die Leistung konzentrieren, sollten sie Ihnen helfen, allgemeine Ideen zur Einbindung von Stakeholdern zu erhalten.

Hero-Foto von JC Gellidon auf Unsplash