Aktivieren Sie die Offline-Unterstützung in Webanwendungen mit Service Workers

Stellen Sie sich jemanden vor, der auf Ihrem Site surft, während er mit dem Zug unterwegs ist – sein Signal bricht alle paar Sekunden ab und wird wiederhergestellt. Auf den meisten Webseiten bedeutet eine solch instabile Verbindung ein Ende: Ein Browserfehler informiert den Nutzer darüber, dass er offline ist. Was wäre jedoch, wenn Ihre Site dieses Problem vollständig umgehen und dennoch weiterhin funktionieren könnte?

Es handelt sich dabei nicht um eine experimentelle zukünftige Funktion. Dies ist bereits jetzt mithilfe einer Browsertechnologie namens Service Worker möglich. Ein Service Worker fungiert wie ein skriptbarer Vermittler zwischen Ihrer Webanwendung und dem Netzwerk. Er kann Ausgangsanfragen abfangen, bevor sie den Server erreichen, und diese selbst mit lokal gespeicherten Dateien beantworten – dadurch bleibt Ihre Site auch ohne jegliche Verbindung funktionsfähig.

Dieser Trick bietet nicht nur eine nützliche Alternative – er kann die Ladezeiten deutlich verkürzen und Ihre Anwendung gegen schlechte Netzverbindungen viel widerstandsfähiger machen. Obwohl er anspruchsvoll klingt, ist die Einrichtung recht einfach.

Was diesen Trick ermöglicht: Service Workers in Kombination mit der Cache API

Zwei Browserfunktionen arbeiten zusammen, um dies möglich zu machen:

1. Service Worker: ein Hintergrundskript, das unabhängig vom Hauptthread der Seite läuft und als Ersatz für die Netzwerkschicht fungiert.
2. Cache API: eine eingebaute Browser-Schnittstelle, mit der Sie Ressourcen programmgesteuert speichern und abrufen können, ähnlich wie in einem Schlüssel-Wert-Speicher. Hier lagern Sie das HTML, CSS, JavaScript, Bilder sowie andere Ressourcen, von denen Ihre Website abhängt.

So verläuft der allgemeine Ablauf: Beim ersten Besuch Ihrer Website über das Internet installiert sich der Service Worker und lädt die wichtigen Dateien in seinen Cache. Ab diesem Zeitpunkt gehen alle Netzwerkanfragen Ihrer Seite zunächst über den Service Worker. Wenn der Besucher die Verbindung verliert, reagiert der Worker mit dem bereits im Cache gespeicherten Inhalt, anstatt versuchen – und scheitern – zu müssen, auf den Server zuzugreifen, sodass die Seite weiterhin fast sofort angezeigt wird.

Schritt 1: Das Service-Worker-Skript schreiben

Erstellen Sie zunächst eine Datei mit dem Namen sw.js im Wurzelverzeichnis Ihres Projekts. Dieses Skript ist dafür verantwortlich, den Cache zu installieren und zukünftige Anfragen abzufangen.

// sw.js

const CACHE_NAME = 'my-website-cache-v1';
const urlsToCache = [
  '/',
  '/index.html',
  '/styles.css',
  '/script.js',
  '/images/logo.png'
];

// The 'install' event is fired when the service worker is first installed.
self.addEventListener('install', event => {
  event.waitUntil(
    caches.open(CACHE_NAME)
      .then(cache => {
        console.log('Opened cache');
        return cache.addAll(urlsToCache);
      })
  );
});

// The 'fetch' event is fired for every network request.
self.addEventListener('fetch', event => {
  event.respondWith(
    caches.match(event.request)
      .then(response => {
        // If the request is in the cache, serve the cached version.
        if (response) {
          console.log('Serving from cache:', event.request.url);
          return response;
        }

        // Otherwise, fetch from the network.
        console.log('Fetching from network:', event.request.url);
        return fetch(event.request);
      })
  );
});

Diese Datei lauscht hauptsächlich auf zwei Lebenszyklusereignisse:

• install: Hier öffnet man einen benannten Cache und füllt ihn mit der Liste der Dateien, die auch ohne Netzwerkverbindung verfügbar sein sollen.
• fetch: Dieses Ereignis tritt bei jeder Anfrage der Seite auf. Der Worker prüft, ob bereits eine entsprechende Antwort im Cache vorhanden ist; falls ja, wird diese gespeicherte Kopie zurückgegeben, andernfalls wird die Anfrage wie gewohnt an das Netzwerk gesendet.

Schritt 2: Den Worker aus Ihrer App registrieren

Sobald das Worker-Skript vorhanden ist, muss dem Browser dennoch mitgeteilt werden, dass er es verwenden soll. Fügen Sie den folgenden Codeausschnitt zu Ihrer Hauptskriptdatei hinzu oder fügen Sie ihn inline in eine <script>-Tagge in Ihrem HTML ein.

// Register the service worker
if ('serviceWorker' in navigator) {
  window.addEventListener('load', () => {
    navigator.serviceWorker.register('/sw.js')
      .then(registration => {
        console.log('Service Worker registered successfully:', registration);
      })
      .catch(error => {
        console.error('Service Worker registration failed:', error);
      });
  });
}

Dieser Block prüft zunächst, ob der aktuelle Browser überhaupt die Service Worker API unterstützt, und registriert bei positivem Ergebnis Ihre sw.js-Datei. Beachten Sie den zum Registrieren verwendeten Pfad: /sw.js muss sich im Wurzelverzeichnis Ihrer Website befinden, da ein Service Worker nur die Seiten steuern kann, die zum Verzeichnisbereich gehören, aus dem er registriert wurde.

Überprüfung der Funktionsfähigkeit

Um dies in Aktion zu sehen, laden Sie Ihre Website in einem Browser hoch, der Service Workers unterstützt – Chrome, Firefox und Edge eignen sich dafür.

• Öffnen Sie die Entwicklertools des Browsers (F12 oder Ctrl+Shift+I).
• Wechseln Sie zum Application-Panel.
• In der Seitenleiste finden Sie Service Workers. Ihre sw.js-Datei sollte dort als aktiv angezeigt werden.

Klicken Sie auf Cache Storage, um zu überprüfen, ob Ihr benannter Cache existiert und die von Ihnen aufgelisteten Dateien enthält.

Klicken Sie das Kontrollkästchen „Offline“ oben in der Service Worker-Seite an.

Laden Sie die Seite neu.

Falls alles richtig eingestellt ist, lädt die Seite sofort, auch ohne Netzwerkzugang. Die Ausgabe in den Entwicklertools bestätigt, dass die Anfragen direkt aus dem Cache und nicht über das Netzwerk abgewickelt werden.

Weiterentwicklung des Musters: Alternative Caching-Strategien

Was gerade beschrieben wurde, wird als Cache-first, Network-Fallback-Ansatz bezeichnet – ideal für Ressourcen, die selten ändern, wie statische Bilder oder gebündelte Skripte. Doch Service Workers sind nicht auf dieses eine Muster beschränkt; es gibt noch einige weitere gängige Strategien:

• Netzwerk zuerst, Cache als Ersatz: geeignet für Inhalte, die sich häufig ändern und aktuell bleiben müssen. Der Worker versucht zunächst, Daten über das Netzwerk abzurufen, und greift nur dann auf den Cache zurück, wenn dieser Aufruf fehlschlägt – beispielsweise aufgrund einer schlechten Verbindung.
• Stale-while-revalidate: Der Worker antwortet sofort mit dem bereits im Cache gespeicherten Inhalt, um Geschwindigkeit zu gewährleisten, während gleichzeitig im Hintergrund eine Netzwerkanfrage gestartet wird, um den Cache beim nächsten Seitenladen zu aktualisieren. So erhalten Sie sofort schnelle Antworten und aktualisierte Inhalte kurz darauf.

Das Beherrschen dieses grundlegenden Offline-Musters bereitet Sie außerdem darauf vor, vollständige Progressive Web Apps zu entwickeln, bei denen die Offline-Funktionalität mit Funktionen wie Push-Benachrichtigungen sowie der Möglichkeit kombiniert wird, die Seite wie eine native App auf dem Startbildschirm eines Geräts zu installieren.

Diese Vorgehensweise in Ihr Projekt einzubauen ist eine relativ geringe Investition mit erheblichem Nutzen: Anstelle dass eine unterbrochene Verbindung das Erlebnis völlig zerstört, bemerken Ihre Nutzer die Unterbrechung kaum.