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.
• Die Analyse der Offlineaktivitäten würde den Analyseserver nie erreichen, da der Nutzer offline ist.
• Ob ein Zeitstempel lokal erfasst und die Offlineaktivität an den Analytics-Server gesendet wird, wenn der Nutzer wieder online ist, hängt davon ab, ob er Ihre Website noch einmal 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 (was 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 dies 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 es in einem Workbox-basierten Dienstworker mit diesen beiden Zeilen aktiviert werden:

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

googleAnalytics.initialize();

So werden alle vorhandenen Ereignisse und Seitenaufruf-Pings erfasst, während Sie offline sind. Sie werden jedoch nicht als offline erkannt, da sie einfach so wiedergegeben werden. Dazu können Sie Trackinganfragen mit Workbox manipulieren, indem Sie dem Analytics-Ping ein offline-Flag mit einer benutzerdefinierten Dimension hinzufügen (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 jedoch einen Nachteil: Das vorhandene Tracking ist zwar offlinefähig, Sie erhalten aber höchstwahrscheinlich erst dann viele relevante Daten, 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 neue Inhalte werden dynamisch über AJAX geladen, ohne dass der Browser gewechselt werden muss. Nutzer sehen die Browserfehlerseite nicht, 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. Möglicherweise wurde die Seite beispielsweise online geladen, der Nutzer war aber offline, bevor er scrollte. Alle Inhalte, die unterhalb des Folds per Lazy Loading geladen werden, werden nicht angezeigt.

Da diese Fälle für Nutzer sehr ärgerlich sind, ist es sinnvoll, sie zu erfassen. 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, der die Seite über fehlgeschlagene Anfragen informiert, indem ein Nachrichtenereignis gesendet wird:

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 ist die Implementierung von registerRoute mit einem benutzerdefinierten Handler. So wird die Geschäftslogik in einem separaten Pfad verpackt, was die Wartbarkeit in komplexeren Serviceworkern 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 unter 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 zuerst mit einer einfachen Offline-Fehlerseite. Mit Workbox ist das ganz einfach. Außerdem sollte sie als UX-Best Practice betrachtet werden, ähnlich wie benutzerdefinierte 404-Seiten. Dann können Sie sich an erweiterte Offline-Fallbacks und schließlich an echte Offlineinhalte herantasten. Wenn Sie diese Funktion gut bewerben und Ihren Nutzern erklären, wird sie immer häufiger genutzt. Schließlich ist jeder hin und wieder offline.

In den Artikeln Messwerte erfassen und eine Leistungskultur schaffen und Websitegeschwindigkeit funktionsübergreifend optimieren finden Sie Tipps, wie Sie funktionsübergreifende Stakeholder dazu bewegen können, mehr in Ihre Website zu investieren. Auch wenn sich diese Beiträge auf die Leistung konzentrieren, sollten sie Ihnen allgemeine Ideen dazu geben, wie Sie Stakeholder ansprechen können.

Hero-Foto von JC Gellidon auf Unsplash.