Progressive Web Apps 2026: Eine Anleitung zum Erstellen

Anna Kowalski Senior Mobile Engineer, YuSMP Group · Entwickelt React Native, Flutter und PWA-Produkte für US- & EU-Kunden seit 2017

Was macht eine PWA zur PWA

Der Begriff Progressive Web App wurde 2015 von den Google-Ingenieuren Alex Russell und Frances Berriman geprägt. Ein Jahrzehnt später hat sich das Konzept von einem Browser-Experiment zu einer echten Produktionsstrategie entwickelt, die von Unternehmen wie Twitter (jetzt X Lite), Pinterest, Starbucks und Uber eingesetzt wird. Das Wort „progressiv" bezieht sich auf den geschichteten Ansatz: Eine PWA ist im Kern eine Webanwendung, die ihr Verhalten schrittweise verbessert, je mehr der Browser-Umgebung unterstützt.

Drei technische Säulen definieren eine PWA:

• Service Worker. Eine JavaScript-Datei, die in einem separaten Thread läuft, als Netzwerk-Proxy zwischen Browser und Internet fungiert und Offline-Funktionalität, Hintergrund-Sync und Push-Benachrichtigungen ermöglicht.
• Web App Manifest. Eine JSON-Datei, die dem Browser mitteilt, wie die App bei der Installation dargestellt werden soll – Name, Icons, Designfarbe, Anzeigemodus und Start-URL.
• HTTPS. Service Worker erfordern einen sicheren Kontext. Jede Produktions-PWA muss über HTTPS bereitgestellt werden (localhost ist bei der Entwicklung ausgenommen).

Über diese drei Säulen hinaus umfasst der PWA-Funktionsumfang die Push API, die Background Sync API, die Badging API, die File System Access API, Web Bluetooth, Web NFC und die Screen Wake Lock API. Die Browser-Unterstützung variiert – weshalb der „progressive" Ansatz so wichtig ist. Ihr Kernerlebnis funktioniert überall; erweiterte Funktionen greifen, wo sie verfügbar sind.

Wenn Sie noch entscheiden, ob eine PWA die richtige Architektur für Ihr Produkt ist, analysiert unser Artikel Web App vs. Native vs. PWA: Wie Sie 2026 wählen den vollständigen Kosten-, Reichweiten- und Fähigkeits-Kompromiss. Diese Anleitung setzt voraus, dass Sie die Entscheidung getroffen haben und entwickeln möchten.

Service Worker: der Motor unter der Haube

Ein Service Worker ist das wichtigste Element einer PWA. Ein tiefes Verständnis davon verhindert die häufigsten Produktionsfehler – veraltete Caches, Update-Verzögerungen, fehlerhafte Offline-Fallbacks – die PWAs einen schlechten Ruf einbringen, wenn sie nachlässig implementiert werden.

So funktioniert der Lebenszyklus:

1. Registrierung. Die Hauptseite registriert das Service-Worker-Skript: navigator.serviceWorker.register('/sw.js'). Der Browser lädt das Skript herunter und parst es in einem separaten Thread.
2. Installation. Das install-Event wird ausgelöst. Hier öffnen Sie einen Cache und precachen Ihr App-Shell – den minimalen Satz an HTML, CSS und JS, der zum Rendern der Benutzeroberfläche ohne Netzwerk benötigt wird.
3. Aktivierung. Nach der Installation wartet der neue Service Worker, bis alle Tabs mit der alten Version geschlossen sind, bevor er aktiviert wird. Während des activate-Events löschen Sie alte Caches. Der Aufruf von self.skipWaiting() erzwingt eine sofortige Aktivierung (nützlich in der Entwicklung; in der Produktion vorsichtig einsetzen).
4. Fetch-Abfang. Sobald er aktiv ist, fängt der Service Worker über das fetch-Event jede Netzwerkanfrage von den kontrollierten Seiten ab. Hier leben die Caching-Strategien.
5. Leerlauf und Beendigung. Der Browser kann einen inaktiven Service Worker jederzeit beenden, um Speicher zu sparen. Er wird bei Bedarf neu gestartet. Speichern Sie niemals Zustände in globalen Service-Worker-Variablen – verwenden Sie stattdessen IndexedDB oder die Cache API.

Caching-Strategien in der Praxis

Der fetch-Handler des Service Workers ist der Ort, an dem Sie entscheiden, wie jeder Ressourcentyp bereitgestellt wird. Es gibt keine einheitlich beste Strategie – der richtige Ansatz hängt davon ab, wie oft sich die Ressource ändert und wie viel Veraltung akzeptabel ist.

Workbox (von Google) ist die De-facto-Standardbibliothek für die Implementierung dieser Muster. Sie verwaltet Precaching mit Integritäts-Hashes, Laufzeit-Caching mit Ablauf-Plugins und Cache-Namen über Service-Worker-Updates hinweg. Sofern Sie keinen zwingenden Grund haben, Caching-Logik von Hand zu schreiben, verwenden Sie Workbox.

Die vier Muster, die Sie in fast jeder PWA verwenden werden:

• Cache-First. Cache zuerst prüfen; Netzwerk nur dann verwenden, wenn die Ressource nicht gecacht ist. Ideal für statische Assets (Schriftarten, Icons, versionierte JS/CSS-Bundles), die sich selten ändern.
• Network-First. Netzwerk versuchen; bei Fehler auf Cache zurückgreifen. Am besten für API-Endpunkte geeignet, bei denen Aktualität kritisch ist.
• Stale-While-Revalidate. Sofort aus dem Cache bedienen, dann den Cache im Hintergrund vom Netzwerk aktualisieren. Balanciert Geschwindigkeit und Aktualität für Ressourcen, die sich regelmäßig aktualisieren.
• Network-Only. Immer das Netzwerk verwenden; niemals den Cache. Für Analytics-Pings, Zahlungen, Login/Logout oder jede Anfrage, bei der veraltete Daten niemals akzeptabel sind.

Web App Manifest und Installierbarkeit

Das Web App Manifest ist eine JSON-Datei, die definiert, wie Ihre PWA bei der Installation aussieht und sich verhält. Chromelighthouse prüft es und meldet Fehler; der Browser verwendet es, um den Install-Prompt und das installierte App-Icon zu generieren.

Wichtige Manifest-Felder für 2026:

• id (neu in 2023). Ein stabiler Bezeichner für die App. Wenn Sie start_url ändern, stellt die Angabe von id sicher, dass der Browser die neue Version als Update der bestehenden installierten App behandelt.
• screenshots. Erforderlich für die „reichhaltigere Install-UI", die Android 14 + Chrome 119+ vor dem Install-Prompt anzeigt.
• Maskierbare Icons. Android adaptive Icons werden zu einem Kreis, Squircle oder einer anderen Form beschnitten. Ohne maskierbares Icon erscheint Ihr Logo mit weißem Abstand innerhalb der Form.
• display: "standalone". Die installierte App blendet das Browser-Chrome (Adressleiste) aus und sieht wie eine native App aus.

Install-Prompts und Zum-Startbildschirm-Hinzufügen

Die Benutzer dazu zu bringen, Ihre PWA zu installieren, ist ein Konversionsereignis wie jedes andere. Die Standard-Browser-Install-UI ist leicht zu übersehen. Der Aufbau eines benutzerdefinierten Install-Prompts verbessert die Installationsraten erheblich.

Auf Android (Chrome): Der Browser löst das beforeinstallprompt-Event aus, wenn alle Installierbarkeits-Kriterien erfüllt sind. Erfassen Sie es und lösen Sie es bei einer Benutzeraktion aus. Verfolgen Sie die Installationsrate als Produktkennzahl. A/B-Test des Zeitpunkts des Install-Prompts – das Anzeigen nach einer sinnvollen Aktion des Benutzers konvertiert deutlich besser als das Anzeigen beim ersten Laden.

Auf iOS (Safari): Es gibt kein beforeinstallprompt-Event. Der Benutzer muss manuell auf die Schaltfläche „Teilen" und dann auf „Zum Startbildschirm" tippen. Ihre beste Option ist ein Modal, das nach einigen Besuchen erscheint und die Geste mit einer kurzen Animation erklärt.

Entwicklung für den Offline-Modus

Offline-Unterstützung ist die Funktion, die eine PWA am deutlichsten von einer Standard-Webanwendung unterscheidet. Gut umgesetzt liefert sie ein vollständiges oder eingeschränktes, aber nützliches Erlebnis, wenn der Benutzer kein Netzwerk hat.

Das grundlegende Muster ist die App-Shell: Precachen Sie den minimalen Satz an Assets, der zum Rendern des UI-Skeletts benötigt wird, und stellen Sie sie bei jedem Laden aus dem Cache bereit. Dynamische Inhalte werden dann vom Netzwerk oder einem lokalen Cache geladen. Google Maps, Twitter Lite und Starbucks verwenden alle dieses Muster.

Über die App-Shell hinaus unterstützen drei APIs die Offline-Funktionalität:

• Cache API. Schlüssel-Wert-Speicher für Request/Response-Paare. Workbox umschließt sie mit Ablauf, Bereinigung und Versionierung.
• IndexedDB. Eine vollständige clientseitige Datenbank mit Transaktionen, Indizes und Cursors. Bibliotheken wie Dexie.js machen die API ergonomisch.
• Background Sync API. Stellt Netzwerkanfragen in die Warteschlange, die offline gestellt wurden, und sendet sie erneut, wenn die Verbindung wiederhergestellt wird.

Push-Benachrichtigungen von A bis Z

Push-Benachrichtigungen sind eines der leistungsstärksten Re-Engagement-Tools für eine PWA – und eines der am häufigsten missbrauchten. Wenn Sie die Berechtigungsanfrage falsch gestalten, blockieren Benutzer Ihre App sofort. Wenn Sie Zeitpunkt und Inhalt richtig gestalten, können Sie Engagement-Raten erzielen, die mit nativen Apps mithalten.

Der technische Ablauf hat fünf Schritte:

1. Berechtigung anfordern. Rufen Sie Notification.requestPermission() innerhalb einer Benutzeraktion auf (Button-Klick, nicht beim Laden der Seite).
2. Push-Dienst abonnieren. Rufen Sie registration.pushManager.subscribe() mit Ihrem VAPID-öffentlichen Schlüssel auf.
3. Subscription auf Ihrem Server speichern. Senden Sie das PushSubscription-JSON per POST an Ihre API.
4. Vom Server senden. Verwenden Sie das Web-Push-Protokoll, um eine verschlüsselte Nutzlast an den Endpunkt zu senden.
5. Im Service Worker anzeigen. Der Service Worker empfängt ein push-Event und ruft self.registration.showNotification() auf.

iOS-Hinweis: Push-Benachrichtigungen für Home-Screen-PWAs werden ab iOS 16.4 unterstützt. Die PWA muss auf dem Startbildschirm installiert sein – Push funktioniert nicht für PWAs, die im Browser-Tab auf iOS laufen.

PWA-Fähigkeiten: iOS vs. Android in 2026

Die Plattformparität zwischen iOS und Android hat sich in den letzten drei Jahren erheblich verbessert, aber bedeutende Lücken bleiben bestehen. Diese Tabelle ist ab Mitte 2026 auf Basis von WebKit 17.x und Chrome 125 aktuell:

Wann eine PWA die richtige Wahl ist

Mit einem klaren Bild davon, was PWAs 2026 können und nicht können, hier ein praktisches Entscheidungsframework:

Entwickeln Sie eine PWA, wenn:

• Ihr primärer Vertriebskanal die Web-Suche (SEO) ist und Sie die Auffindbarkeit nicht zwischen App Store und Webseite aufteilen möchten.
• Ihre Benutzer auf einer Vielzahl von Geräten und Betriebssystemen sind – B2B-SaaS-Benutzer auf Windows-Laptops, Außendienstmitarbeiter auf Android und Manager auf iPhones treffen alle dieselbe URL.
• Ihr Offline-Bedarf moderat ist – gecachte Inhalte, in der Warteschlange stehende Formularübermittlungen, einfache CRUD-Operationen aus einer lokalen IndexedDB.
• Budgetbeschränkungen separate iOS- und Android-native Codebasen unpraktikabel machen.
• Sie ein inhaltslastiges Produkt entwickeln (News, Dokumentation, Kurse, E-Commerce-Katalog), bei dem App-Store-Review-Latenz Content-Updates verlangsamen würde.

Erwägen Sie stattdessen Native oder React Native, wenn:

• Sie Bluetooth, NFC, kontinuierliches Background-GPS oder erweiterte AR-Fähigkeiten benötigen.
• Ihr Produkt ein Spiel oder ein Audio-/Video-Streaming-Erlebnis ist.
• Ihre iOS-Benutzer ein bedeutendes Segment sind und Push-Benachrichtigungen im Browser-Tab (nicht nur wenn die PWA installiert ist) benötigen.
• App-Store-Präsenz ein Vertrauenssignal in Ihrem Markt ist – Enterprise-Käufer in regulierten Branchen erwarten oft eine Auflistung in Apple Business Manager oder Google Play.

Für viele B2B-SaaS-Produkte, E-Commerce-Plattformen und Produktivitätswerkzeuge ist eine PWA 2026 die Wahl mit dem höchsten ROI. Vergleichen Sie auch unseren Artikel Web App vs. Native vs. PWA: Wie Sie 2026 wählen für die vollständige Kosten- und Reichweitenanalyse. Unser Web-App-Entwicklungsservice umfasst PWAs als erstklassigen Output.

PWA-Build-Checkliste

Verwenden Sie diese Checkliste vor dem Deployen einer PWA in die Produktion. Sie spiegelt die Kriterien wider, die Lighthouse für sein PWA-Audit verwendet, ergänzt um Produktionsreife-Elemente:

FAQ

Was ist eine Progressive Web App und wie unterscheidet sie sich von einer normalen Web-App?

Eine Progressive Web App ist eine Webanwendung, die moderne Browser-APIs – hauptsächlich Service Worker, das Web App Manifest und die Push API – nutzt, um ein natives App-Erlebnis zu bieten. Im Gegensatz zu einer normalen Web-App kann sie offline funktionieren, Assets für nahezu sofortige Ladezeiten cachen, Push-Benachrichtigungen empfangen und ohne App-Store auf dem Startbildschirm installiert werden.

Funktionieren PWAs auf iOS im Jahr 2026?

Ja, mit Einschränkungen. iOS 16.4+ unterstützt Web Push (einschließlich Home-Screen-PWAs), Background Sync, die Badging API und Persistent-Storage-Anfragen. Allerdings fehlen auf iOS weiterhin Background Fetch, volles Bluetooth- und NFC-Zugriff sowie Screen Wake Lock. Der Installationsablauf auf iOS erfordert ein manuelles Tippen – es gibt keine systemeigene Install-Aufforderung. Für die meisten inhaltsorientierten, Commerce- und Produktivitäts-PWAs ist der iOS-Support 2026 ausreichend.

Welche Caching-Strategie sollte ich für meine PWA verwenden?

Das hängt vom Ressourcentyp ab. Verwenden Sie Cache-First für statische Assets, die sich selten ändern. Network-First für API-Aufrufe, bei denen Aktualität kritisch ist. Stale-While-Revalidate für Seiten, bei denen leicht veralteter Inhalt akzeptabel ist, Sie aber schnelle Ladezeiten wünschen. Workbox von Google automatisiert alle drei Muster.

Wie löse ich den Install-Prompt auf Android aus?

Android Chrome löst das beforeinstallprompt-Event aus, wenn die PWA die Installierbarkeits-Kriterien erfüllt: HTTPS, gültiges Manifest mit Name, Short Name, Icons (mindestens 192x192 und 512x512), Start-URL und Display auf standalone oder fullscreen, plus ein registrierter Service Worker mit Fetch-Handler. Erfassen Sie das Event und rufen Sie prompt() auf, wenn der Benutzer Ihren Install-Button anklickt.

Kann eine PWA Push-Benachrichtigungen senden?

Ja. Die Push API in Kombination mit der Notifications API ermöglicht Push-Benachrichtigungen über einen serverseitigen Push-Dienst. Auf iOS erfordert dies eine als Home-Screen-App installierte PWA (iOS 16.4+).

Wann sollte ich eine PWA statt einer nativen App entwickeln?

Eine PWA ist die richtige Wahl, wenn Ihr primärer Kanal Web-Suche ist, Sie Benutzer geräteübergreifend ohne App-Store-Reibung erreichen müssen, Ihr Offline-Bedarf moderat ist und Sie keine Bluetooth-, NFC- oder tiefe OS-Integration benötigen. Wenn Sie diese Hardware-APIs benötigen, ist Native oder React Native die bessere Wahl. Sehen Sie unseren vollständigen Vergleich unter Web App vs. Native vs. PWA.

Wie groß kann der Cache einer PWA sein?

Speicherkontingente hängen vom Browser und dem verfügbaren Speicherplatz ab. Chrome gewährt ca. 60 % des gesamten Speicherplatzes. Planen Sie Ihren Cache sorgfältig: Precachen Sie nur Shell-Assets (in der Regel unter 5 MB) und cachen Sie API-Antworten selektiv mit Ablaufgrenzen.

Zuletzt aktualisiert am 16. Juni 2026. Technische Details basieren auf den WebKit-17.x- und Chrome-125+-Unterstützungsmatrizen Stand Mitte 2026.