Das Internet-Lexikon

Progressive Web Apps erklärt

Wie die drei technischen Bausteine einer PWA tatsächlich zusammenspielen, wo die Grenzen zwischen den Plattformen liegen, und ein Entscheidungsrahmen für native App, PWA oder responsive Website.

Für viele Unternehmen stellt sich früher oder später die Frage: native App oder Website? Progressive Web Apps (PWAs) bieten einen dritten Weg dazwischen - mit eigenen Stärken und klaren, plattformabhängigen Grenzen, die in der Praxis regelmäßig unterschätzt werden.

1. Die drei technischen Bausteine

Eine PWA basiert im Kern auf drei Web-Technologien: einem Service Worker, der im Hintergrund Inhalte zwischenspeichert und Offline-Funktionalität ermöglicht, einem Web App Manifest (einer JSON-Datei mit App-Namen, Icons und Startverhalten), und einer über HTTPS ausgelieferten Website als Grundlage. Erst das Zusammenspiel aller drei macht eine Website zur installierbaren, app-ähnlichen PWA - fehlt einer der drei Bausteine, bleibt die Website eine gewöhnliche Website, auch wenn die anderen beiden korrekt umgesetzt sind.

2. Der Service Worker als eigentlicher Motor

Der Service Worker ist ein JavaScript-Programm, das der Browser getrennt vom eigentlichen Seiten-Thread ausführt und das laufen kann, auch wenn keine Browser-Registerkarte mit der Seite geöffnet ist. Er durchläuft einen eigenen Lebenszyklus (Installation, Aktivierung, danach das Abfangen von Netzwerk-Anfragen) und entscheidet bei jeder Anfrage, ob eine Ressource aus dem lokalen Cache, aus dem Netzwerk oder aus einer Kombination beider Quellen ausgeliefert wird. Gängige Caching-Strategien sind “Cache-First” (schnell, aber potenziell veraltet), “Network-First” (aktuell, aber langsamer bei schlechter Verbindung) und “Stale-While-Revalidate” (sofortige Antwort aus dem Cache, im Hintergrund aktualisiert für den nächsten Aufruf). Welche Strategie sinnvoll ist, hängt vom Inhaltstyp ab - statische Assets wie Icons oder CSS vertragen Cache-First problemlos, sich häufig ändernde Daten wie Preise oder Lagerbestände brauchen eher Network-First.

3. Offline-Fähigkeit: was tatsächlich funktioniert

“Offline-fähig” bedeutet in der Praxis fast nie, dass die gesamte Anwendung offline vollständig nutzbar ist. Realistisch lassen sich zuvor besuchte Inhalte aus dem Cache anzeigen, eine Offline-Fallback-Seite statt eines Browser-Fehlers ausliefern, und mit zusätzlichem Aufwand (etwa über die Background-Sync-Fähigkeiten moderner Browser) Formulareingaben zwischenspeichern und später automatisch übertragen, sobald wieder eine Verbindung besteht. Inhalte, die zum Zeitpunkt der Offline-Nutzung noch nie geladen wurden, bleiben grundsätzlich nicht verfügbar - ein Service Worker kann nichts anzeigen, was er nie im Cache abgelegt hat.

4. Installierbarkeit unterscheidet sich stark je Plattform

Unter Android und Desktop-Chrome erkennt der Browser eine installierbare PWA automatisch und kann eine native Installations-Aufforderung anzeigen, sofern Manifest, Service Worker und HTTPS vorhanden sind. Unter iOS gibt es diesen automatischen Installationsdialog nicht: Nutzer müssen die Seite manuell über “Zum Home-Bildschirm” im Teilen-Menü von Safari hinzufügen. Das ist ein zusätzlicher, für viele Nutzer unbekannter Schritt und einer der Hauptgründe, warum PWA-Installationsraten auf iOS in der Praxis niedriger ausfallen als auf Android.

5. Push-Benachrichtigungen: der iOS-Sonderfall

Seit iOS 16.4 unterstützt Apple Web Push auch für PWAs, die zuvor über “Zum Home-Bildschirm” installiert wurden - vorher war diese Funktion auf iOS PWAs schlicht nicht verfügbar. Wichtig für die Praxis: Die PWA muss auf iOS tatsächlich installiert sein, damit Push-Benachrichtigungen funktionieren; ein einfacher Website-Besuch im Safari-Browser reicht dafür nicht aus, anders als unter Android/Chrome, wo Push-Berechtigungen auch ohne vorherige Installation angefragt werden können.

6. Wo die Grenzen liegen

Der Zugriff auf tiefere Systemfunktionen wie Bluetooth, NFC oder bestimmte Kamerafunktionen ist bei PWAs eingeschränkter als bei nativen Apps, insbesondere unter iOS, wo Apple PWA-Funktionen historisch zögerlicher unterstützt hat. Auch fehlt einer PWA die Sichtbarkeit in App-Stores, über die viele Nutzer neue Apps überhaupt erst entdecken - eine PWA muss ihre Zielgruppe also über den Browser oder bestehende Kanäle erreichen, nicht über Store-Suche.

7. PWA, native App oder responsive Website?

Eine PWA eignet sich besonders für Unternehmen, die eine bestehende Website ohne den Aufwand zweier separater nativer Codebasen (iOS und Android) app-ähnlich erweitern wollen, oder für Zielgruppen, die primär über den Browser statt App-Stores auf ein Angebot zugreifen. Für Anwendungen mit hohem Bedarf an tiefer Geräteintegration, maximaler Performance oder Store-Sichtbarkeit als Entdeckungskanal bleibt eine native App häufig die bessere Wahl. Für Inhalte, die keine Installation und keine Offline-Nutzung erfordern, ist oft schon eine gut optimierte responsive Website ausreichend - nicht jede Website profitiert automatisch vom zusätzlichen Aufwand einer PWA-Umsetzung.

8. Zusammenspiel mit Performance und Core Web Vitals

Ein Service Worker beeinflusst die Core Web Vitals einer Website direkt: Werden wiederkehrende Besuche aus dem Cache statt vom Netzwerk bedient, verbessert das typischerweise Ladezeit-Metriken spürbar. Gleichzeitig kann ein schlecht konfigurierter Service Worker das Gegenteil bewirken - etwa wenn er bei jeder Anfrage unnötig lange im Hintergrund prüft, ob eine neuere Version vorliegt, bevor er überhaupt antwortet.

9. Häufige Fehler

Der verbreitetste Fehler ist, eine PWA rein technisch korrekt umzusetzen, aber die Installations-Aufforderung für Nutzer schlecht oder gar nicht sichtbar zu platzieren - viele Nutzer wissen schlicht nicht, dass eine Website überhaupt installierbar ist, wenn nicht aktiv darauf hingewiesen wird. Ein zweiter häufiger Fehler betrifft Service-Worker-Updates: Wird eine neue Version des Service Workers ausgeliefert, aktiviert sie sich standardmäßig nicht sofort, sondern erst, wenn alle offenen Tabs mit der alten Version geschlossen wurden - ohne explizite Update-Logik im Code sehen Nutzer dadurch mitunter tagelang eine veraltete, gecachte Version der Anwendung. Ein dritter Fehler ist ein zu weit gefasster Cache-Geltungsbereich (Scope), der versehentlich Bereiche der Website erfasst, die eigentlich nicht vom Service Worker kontrolliert werden sollten.

10. Wie prüfst du das

Die Chrome-DevTools bieten unter “Application” einen eigenen Bereich für Service Worker (samt Status, Lebenszyklus und manuellem Update-Erzwingen) und für den Cache Storage, in dem sich einsehen lässt, welche Ressourcen tatsächlich zwischengespeichert sind. Lighthouse, ebenfalls in den Chrome-DevTools integriert, prüft gezielt die PWA-relevanten Kriterien (Manifest vorhanden und valide, Service Worker registriert, HTTPS aktiv, Offline-Fallback vorhanden) und zeigt fehlende Voraussetzungen konkret an. Für die Installierbarkeit auf iOS gibt es kein vergleichbares automatisiertes Prüfwerkzeug - hier hilft nur der manuelle Test auf einem echten Gerät.

11. Entscheidungsrahmen

  1. Brauchen Nutzer Offline-Zugriff oder ein Homescreen-Icon, aber keine tiefe Geräteintegration? → PWA ist meist die richtige Wahl.
  2. Ist die Zielgruppe stark iOS-lastig und auf Push-Benachrichtigungen oder eine reibungslose Installation angewiesen? → Die iOS-Einschränkungen (manuelle Installation, eingeschränkte Push-Historie) sorgfältig gegen eine native App abwägen.
  3. Ist Store-Sichtbarkeit als Entdeckungskanal geschäftskritisch? → Native App, da PWAs in App-Stores nicht auffindbar sind.
  4. Reicht eine gut optimierte, schnelle Website ohne Installation aus? → Kein PWA-Aufwand nötig, Fokus auf Performance und Core Web Vitals.
  5. Ist tiefe Hardware-Integration (Bluetooth, NFC, Kamera-Sonderfunktionen) erforderlich? → Native App.

Weiterführend