» Es gibt Mobile First, Design First, User Experience First, aber heute geht es um Offline First mit Service Worker oddEVEN

Moderne Webanwendungen sollten auch offline zur Verfügung stehen und möglichst viele neue Funktionen bieten können. Damit das funktionier wird ein serviceworker.js benötigt. In Diesem Beitrag werden wir anschauen, wie minimale Offline-Funktionalität eingebaut werden kann.

Lighthouse

Lighthouse ist ein automatisiertes Open Source-Tool zur Verbesserung der Qualität von Webseiten. Es bietet Audits für Leistung, Zugänglichkeit, progressive Webanwendungen und mehr.

Lighthouse funktioniert in Chrome DevTool, in der CLI oder in node.js als Module. Für die Lighthouse Prüfung wird eine URL der Webseite benötigt, die getestet werden soll. Nach der Eingabe der URL wird Lighthouse eine Reihe von Prüfungen durchführen und ein Fehlerbericht generieren.

Die fehlgeschlagenen Prüfungen dienen als Indikatoren zur Verbesserung der Seite. Jede Prüfung verfügt über ein Referenzdokument, in dem erläutert wird, warum die Prüfung wichtig ist, und wie es zu beheben ist.

Es gibt viele Optimierungen, die ohne Service Worker umgesetzt werden können, aber wir werden und heute auf den Offline Support konzentrieren der einen minimalen Einsatz von Service Worker benötigt.

Service Worker Intro

Dieser Artikel behandelt einen JavaScript Service Worker, der unabhändig vom JavaScript Hauptthread im Browser arbeitet. Mit dieser modernen Technologie können Webseiten oder Webapps offline verfügbar gemacht werden.

Wir werden einen Service Worker aufsetzen und alle benötigten Ressourcen für ein offline Zugang im Cache Storage des Browsers ablegen.

Unsere Internet Verbindungsqualität schwankt ständig. Sehr viele Einflüsse können die Qualität unseres Signals beeinträchtigen. Solche Einflüsse sind:

Netzwerk ist überlastet (Im Fussballstadion)
Signalunterbruch in einem Tunnel
Schlechtes Wi-Fi Signal
Die Antwort von einer API dauert zu lang.
Und viele weitere Punkte

Registrieren eines JavaScript Service Worker

Da Service Workers sehr viel auf einer Webseite manipulierten können, ist HTTPS eine Vorraussetzung. GitHub Pages und weitere Anbieter bieten gratis HTTPS an und sind gut für solche Demos geeignet. Natürlich könnt ihr auch auf einem eigenen Server die Demos hosten.

Starten wir doch mit unserer index Datei

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Service Worker Demo</title>
    <link rel="stylesheet" href="style.css">
</head>
<body>
    <a href="https://oddeven.ch"
         rel="noopener" 
         target"_blank" 
         title="zur oddeven.ch"><img src="oddEVEN.gif" alt="oddEVEN"></a>
    <script src="script.js"></script>
</body>
</html>

Der Service Worker wird beim ersten Aufruf der Webseite/Webapp geprüft und aus einer script.js Datei auf dem root Scope registriert.
Danach testen wir, ob die Installation erfolgreich war. Der Service Worker wird nicht bei jedem Aufruf der Webseite installiert. Es geschieht nur einmal.

/* script.js */

if ("serviceWorker" in navigator) {
  navigator.serviceWorker
    .register('./serviceWorker.js', {
      scope: './'
    })
    .then(function (reg) {
      console.log("?", reg);
    }, function (err) {
      console.log("?", err)
    });
}

Installation und Precaching

Nach der Registrierung installieren wir unseren ServiceWorker und legen unsere statischen Dateien im Cache Storage des Browsers ab.

self.addEventListener("install", function (event) {
  caches
    .open("Demo")
    .then(function (cache) {
      return cache.addAll([
      	"/",
      	"./index.html", 
        "./styles.css", 
        "./script.js", 
        "./oddEVEN.gif"
    ]);
    })
    .catch(function (err) {
      console.error(err);
    })
})

Beim zweiten Aufruf der Seite wird der Cache unsere Dateien beinhalten. Mehr zum diesen Verhalten gibt es im video von Jake Archibald weiter unten im Artikel.

The Service Worker Lifecycle

Cache benutzen

Jetzt dient der Service Worker als Proxy zwischen dem Client Browser und dem Server. Sobald eine bekannte Datei von dem Client angefragt wird, wird sie aus dem Cache geliefert und nicht von dem Server. Mit dieser Funktionalität liefern wir die Webseite schneller an den Benutzer, und da alle benötigten statischen Dateien von dem Gerät der Benutzers kommen, sparen wir die HTTP calls zum Server.

self.addEventListener("fetch", function(event){
  event.respondWith(
    caches
      .match(event.request)
      .then(function(response) {
        if (response) return response;
        return fetch(event.request);
      })
  );
})

Fazit

Mit einem Service Worker erreichen wir jetzt 100 von 100 Punkte bei Lighthouse und als “schöner Nebeneffekt” 😉 lädt die Webseite Blitzschnell. Der Benutzer kann den Inhalt unserer Seite selbst offline oder bei schlechter Verbindung abrufen.

Ein Service Worker kann auch für andere Zwecke eigesetzt werden, z.B. für
Push Notifications, Background Synchronisation, Load Balancing und mehr.
Die Service Worker API bietet detailierte Dokumentation zu dem Thema.

Dies war nur ein kleines Intro zu diesem Thema.

Es gibt Mobile First, Design First, User Experience First, aber heute geht es um Offline First mit Service Worker