Progressive Web Apps

Was muss ich vorab zu PWA wissen?

Die ursprünglich im Jahr 2015 von Google vorgeschlagene Technologie gewinnt stetig an Bedeutung, da sie leicht zu implementieren ist und einen Mehrwert an User Experience bieten kann. Für Progressive Web Apps wird ein sogenannter Service Worker benötigt, der inzwischen von allen wichtigen Browsern unterstützt wird. Die Verbreitung dieser Technologie beträgt in Deutschland momentan gut 91% und weltweit ca. 94%.

Der Einsatz lohnt sich also, denn alle modernen, mobilen Geräten unterstützen damit den Service Worker (Apple seit macOS Version 10.13.4 und iOS Version 11.3)

Bevor mit der Entwicklung der Progressive Web App (PWA) begonnen wird, sollte man sich vorab Gedanken zum Zweck und Ziel der Funktion machen. Mit Hilfe des Service Workers können folgende Funktionen realisiert werden:

  • Offline Zugriff auf bereits besuchte Seiten und Darstellung einer Offline-Seite
  • Leistungssteigerung durch das lokale Speichern von Ressourcen
  • Nutzung weiterer browserspezifischer Funktionen, z. B. Push-Benachrichtigungen

Diese Dateien werden zum Starten benötigt:

  • manifest.json Titel und Beschreibung der PWA, Icons, Farben und Art der Browser-Darstellung
  • sw.js Service Worker zur Steuerung der PWA

Weiterhin funktioniert der Service Worker nur über eine verschlüsselte HTTPS-Verbindung. Andernfalls wird von Google Chrome die Fehlermeldung „Uncaught (in promise) DOMException: Only secure origins are allowed.“ ausgegeben.

Wie erstelle ich eine Progressive Web App?

Über die manifest.json werden die Parameter für die Progressive Web App definiert. Darunter der kurze Name (Anzeige auf dem Home-Screen), lange Name (Titel der PWA auf dem Splash Screen) und die Beschreibung. Weiterhin werden die Farben, die Icons und die Start-URL für den Browser gesetzt.

Mit Hilfe des display-Attributes wird definiert, ob die PWA nur als Tab im Browser (minimal-ui oder browser) oder als standalone WebView angezeigt werden soll. Wird die PWA im Vollbildmodus ausgeführt, so können über die CSS Pseudo-Klasse :fullscreen Anpassungen am Frontend vorgenommen werden.

Nun muss der Service Worker im Browser, falls dieser diese Funktion unterstützt, registriert werden. Dafür wird das HTML-Template um eine Manifest-Definition und einen Skript-Block erweitert.

Der Service Worker durchläuft einen Lifecycle, der über Event-Listener mit Funktionen angepasst werden kann.

Phase 1: Install

Ist kein Service Worker registriert, wird dieser nach dem Aufruf installiert. Hier werden alle Seiten definiert, die beim Seitenaufruf automatisch im Cache gespeichert werden.

Weiterhin können über Konstanten die Version, der Cache-Name und die Offline-URL gesetzt werden.

Phase 2: Activate

War die Installation erfolgreich, wird der Service Worker aktiviert. Dabei werden alle veralteten Cache-Storages gelöscht. Sollte bereits ein Service Worker installiert und aktiviert sein, werden Phase 1 und 2 übersprungen und es können direkt fetch und message verarbeitet werden.

Phase 3: Fetch / Message

Der Service Worker wartet nun im Idle-Status, bis das Fetch-Event ausgelöst wird. In diesem Fall wird geprüft, ob die Response aus dem Cache-Storage bedient werden kann. Ist dies nicht möglich, gibt es mehrere Möglichkeiten:
a) der Request wird geklont, sein HTTP-Statuscode geprüft und die Antwort im Cache-Storage für zukünftige Anfragen gespeichert oder
b) der Request wieder an den Online-Server weitergegeben.

Sollte die Antwort fehlerhaft sein (offline oder Server-Fehler), wird automatisch die Offline-Seite ausgeliefert.

Phase 4: Redundant

Der Service Worker wird gestoppt, sobald eines der folgende Ereignisse eintritt:

  • Die Installation des Service Workers schlägt fehl
  • Die Aktivierung des Service Workers schlägt fehl
  • Ein neuer Service Worker ersetzt den bestehenden

Wie kann ich die PWA debuggen und analysieren?

Bei Google Chrome können über die Entwicklertools im Tab „Application“ weitere nützliche Informationen abgerufen werden. Sollte dieser fehlen, kann er über die drei vertikalen Punkte unter dem Menüpunkt „More tools“ hinzugefügt werden.

  • Application » Manifest liefert eine Interpretation der `manifest.json` und zeigt die hinterlegten Farben und Icons.
  • Application » Service Workers zeigt, ob ein Service Worker aktiviert wurde und ob bei der Ausführung Fehler aufgetreten sind. Hier kann zu Entwicklungszwecken auch ein Haken bei „Update on reload“ gesetzt werden, womit bei jedem Seitenaufruf der Service Worker automatisch neu installiert wird. Weiterhin kann der Service Worker über Unregister manuell entfernt werden.
  • Application » Clear storage löscht auf Knopfdruck alle Elemente der aktuellen PWA und kann somit den Browser zurückgesetzen.
  • Cache » Cache Storage zeigt alle gecachten Dateien eines Speichers mit Typ, Dateigröße und Erstellungszeit.

Über die Audits kann die PWA anschließend getestet und auf ihr Optimierungspotential hin geprüft werden. Dort kommt das Open-Source Tool Lighthouse zum Einsatz. Es testet sowohl die grundlegenden Bedienungen (serviceWorker registriert, Auslieferung über HTTPS, usw.) als auch zusätzliche Funktionen (Offline-Seite, Splash Screen, usw.).

Alternativ kann Lighthouse auch über die Kommandozeile über das NPM-Paket GoogleChrome/lighthouse genutzt werden.