Diese Seite wurde von der Cloud Translation API übersetzt.

Offlinenutzung messen

Hier erfahren Sie, wie Sie die Offline-Nutzung Ihrer Website erfassen, um zu begründen, warum Ihre Website offline verbessert werden sollte.

Stephan Giesau

Martin Schierle

In diesem Artikel erfährst du, wie du die Offlinenutzung deiner Website nachverfolgen kannst, um zu begründen, warum deine Website einen besseren Offlinemodus benötigt. Außerdem werden Fallstricke und Probleme erläutert, die Sie bei der Implementierung von Analysen zur Offlinenutzung vermeiden sollten.

Die Fallstricke von Online- und Offline-Browserereignissen

Die naheliegendste 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 einzufügen. Leider gibt es bei diesem Ansatz mehrere Probleme und Einschränkungen:

Im Allgemeinen kann das Erfassen jedes Statusereignisses der Netzwerkverbindung übermäßig hoch sein. In einer datenschutzorientierten Welt, in der so wenig Daten wie möglich erfasst werden sollten, ist dies kontraproduktiv. Darüber hinaus können die Ereignisse online und offline nur für den Netzwerkverlust von Sekundenbruchteilen ausgelöst werden, den ein Nutzer wahrscheinlich gar nicht sehen oder bemerken würde.
Das Analyse-Tracking der Offline-Aktivität würde den Analyseserver nie erreichen, da der Benutzer... nun ja, offline ist.
Einen Zeitstempel lokal zu verfolgen, wenn ein Nutzer offline geht, und die Offlineaktivität an den Analyseserver zu senden, wenn er wieder online ist, hängt davon ab, ob der Nutzer Ihre Website noch einmal besucht. Wenn der Nutzer Ihre Website aufgrund eines fehlenden Offlinemodus verlässt und sie nie wieder besucht, können Sie dies nicht erfassen. Die Möglichkeit, Offlineabbrüche zu erfassen, ist entscheidend, um zu verdeutlichen, warum Ihre Website einen besseren Offlinemodus benötigt.
Das Ereignis online ist nicht sehr zuverlässig, da nur der Netzwerkzugriff und nicht der Internetzugriff bekannt sind. Daher ist ein Nutzer möglicherweise immer noch offline und das Senden des Tracking-Pings kann weiterhin fehlschlagen.
Selbst wenn der Nutzer weiterhin auf der aktuellen Seite bleibt, während er offline ist, werden keine anderen Analytics-Ereignisse (z. B. Scroll-Ereignisse, Klicks usw.) erfasst. Daher sind die Informationen möglicherweise relevanter und nützlicher.
Es ist auch nicht allzu bedeutsam, offline zu sein. Als Website-Entwickler ist es möglicherweise wichtiger, zu wissen, welche Arten von Ressourcen nicht geladen werden konnten. Dies ist besonders im Kontext von SPAs relevant, bei denen eine unterbrochene Netzwerkverbindung möglicherweise nicht zu einer Offline-Fehlerseite des Browsers führt (die Nutzer verstehen), sondern eher dazu, dass zufällige dynamische Teile der Seite ohne Rückmeldung ausfallen.

Sie können diese Lösung trotzdem verwenden, um sich ein grundlegendes Verständnis der Offlinenutzung anzueignen. Die vielen Nachteile und Einschränkungen müssen jedoch sorgfältig berücksichtigt werden.

Ein besserer Ansatz: der Service Worker

Die Lösung, die den Offlinemodus aktiviert, ist die bessere Lösung für das Tracking der Offlinenutzung. Die Grundidee besteht darin, Analyse-Pings in IndexedDB zu speichern, solange der Nutzer offline ist, und sie nur noch einmal zu senden, wenn der Nutzer wieder online ist. Für Google Analytics ist dies bereits im Standard über ein Workbox-Modul verfügbar. Beachten Sie jedoch, dass Treffer, die mehr als vier Stunden verzögert gesendet wurden, 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 wieder eine Internetverbindung hergestellt wird? Obwohl dadurch der Service Worker normalerweise in den Ruhemodus versetzt wird (da er die Daten nicht senden kann, wenn die Verbindung wiederhergestellt wird), verwendet das Workbox Google Analytics-Modul die Background Sync API. Diese sendet die Analysedaten später, wenn die Verbindung wiederhergestellt wird, selbst wenn der Nutzer den Tab oder Browser schließt.

Es gibt immer noch einen Nachteil: Dadurch wird zwar das bestehende Tracking offline unterstützt, aber Sie erhalten wahrscheinlich 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 dies zumindest messen und quantifizieren, indem Sie die durchschnittliche Sitzungsdauer und das Nutzer-Engagement für Nutzer mit der angewendeten Offlinedimension mit denen für reguläre Nutzer vergleichen.

SPAs und Lazy Loading

Wenn Nutzer, die eine als mehrseitige Website erstellte Seite besuchen, offline gehen und versuchen, zu navigieren, wird die standardmäßige 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, wechseln in einen undefinierten Zustand oder hören einfach auf, nicht mehr dynamisch zu sein.

Ähnliche Auswirkungen können durch Lazy Loading bei mehrseitigen Websites 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-Loading-Inhalte „below the fold“ (mit Scrollen sichtbar) werden ohne Meldung fehlschlagen und nicht angezeigt.

Da diese Fälle die Nutzer sehr stören, ist es sinnvoll, sie zu beobachten. Service Worker sind der perfekte Ort, um Netzwerkfehler zu erkennen und sie schließlich 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();

  }());
});

Eine andere Möglichkeit besteht darin, nur Fehler auf bestimmten Routen abzufangen, anstatt alle fehlgeschlagenen Anfragen zu überwachen. Wenn beispielsweise Fehler nur bei Routen nach /products/* gemeldet werden sollen, können wir in setCatchHandler eine Prüfung hinzufügen, die den URI mit einem regulären Ausdruck filtert. Eine übersichtlichere 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 auf das message-Ereignis warten und den Analyse-Ping senden. Achten Sie auch hier darauf, Analyseanfragen zu puffern, die offline im Service Worker erfolgen. Initialisieren Sie wie oben beschrieben das workbox-google-analytics-Plug-in für die integrierte Google Analytics-Unterstützung.

Im folgenden Beispiel wird Google Analytics verwendet. Es kann jedoch auch auf 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
      });
    }
  });
}

Dadurch werden fehlgeschlagene Ressourcenladevorgänge in Google Analytics nachverfolgt und wo sie in Berichten analysiert werden können. Die abgeleitete Statistik kann verwendet werden, um das Service Worker-Caching und die Fehlerbehandlung im Allgemeinen zu verbessern. Auf diese Weise wird die Seite auch unter instabilen Netzwerkbedingungen robuster und zuverlässiger.

Nächste Schritte

In diesem Artikel wurden verschiedene Möglichkeiten zum Erfassen der Offlinenutzung mit ihren Vor- und Nachteilen beschrieben. Dies kann Ihnen zwar dabei helfen, zu quantifizieren, wie viele Ihrer Nutzer offline gehen und auf Probleme stoßen, aber es ist noch immer nur ein erster Schritt. Solange Ihre Website keinen gut entwickelten Offlinemodus bietet, werden Sie in Analytics selbstverständlich nur wenig Offlinenutzung feststellen.

Wir empfehlen, das vollständige Tracking einzurichten und dann die Offlinefunktionen schrittweise zu erweitern. Achten Sie dabei auf die Tracking-Nummern. 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 einer benutzerdefinierten 404-Seite ähnelt. Gehen Sie dann erweiterte Offline-Fallbacks und schließlich echte Offlineinhalte vor. Wenn Sie dies gut bewerben und Ihren Nutzern erklären, werden Sie feststellen, dass die Nutzung zunehmen wird. Schließlich gehen alle hin und wieder offline.

Tipps dazu, wie Sie funktionsübergreifende Stakeholder davon überzeugen können, mehr in Ihre Website zu investieren, finden Sie unter Messwerte erfassen und eine Leistungskultur aufbauen und Websitegeschwindigkeit funktionsübergreifend beheben. 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