Progressive Web App (PWA)
Definition: Eine Progressive Web App (PWA) ist eine Webanwendung die mit modernen Web-Technologien so entwickelt wird dass sie sich wie eine native Mobile-App anfühlt und verhält – ohne App-Store-Installation. Technische Grundpfeiler: Service Worker (JavaScript-Hintergrundprozess für Offline-Caching und Push-Benachrichtigungen), Web App Manifest (JSON-Datei für Homescreen-Icon, Splash Screen, App-Name) und HTTPS (Pflichtvoraussetzung). Kernfähigkeiten: Homescreen-Installation («Add to Home Screen»), Offline-Funktion durch Service-Worker-Caching, Web Push Notifications (Android nativ, iOS seit Safari 16.4 mit Einschränkungen), schnelle Ladezeit durch Precaching. Abgrenzung zur nativen App: keine App-Store-Genehmigung nötig, keine 15–30 % Store-Provision, SEO-crawlbar (Suchmaschinen indexieren PWA-Inhalte wie normale Websites), einfachere Updates (kein App-Store-Review), geringere Entwicklungskosten. Bekannte PWA-Beispiele: Twitter Lite (70 % Dateneinsparung, 65 % mehr Sessions), Pinterest PWA (+60 % Engagement), Starbucks PWA (Offline-Menübestellung).
Erläuterung
PWAs sind die strategische Antwort auf das «App-Store-Dilemma»: Native Apps haben höheres Engagement, aber hohe Einstiegshürde (Install-Schritt, Store-Suche, Speicherplatz). Mobile Websites haben niedrige Hürde, aber weniger Funktionen und schlechteres Engagement. PWAs kombinieren beides: Reichweite des Webs + Nutzererfahrung der App. Für Unternehmen ohne Budget oder Priorität für native App-Entwicklung ist eine PWA oft die bessere Alternative zu einer schlechten nativen App.
Technische Grundlagen
- Service Worker: JavaScript-Datei die im Hintergrund des Browsers läuft (eigener Thread); registriert sich beim ersten Seitenaufruf; Funktionen: Netzwerk-Requests abfangen und cachen (Offline-First-Strategie), Push-Nachrichten empfangen, Background Sync; Cache-Strategien: Cache First (statische Assets), Network First (dynamische Daten), Stale While Revalidate; Tools: Workbox (Google-Bibliothek) für Service-Worker-Generierung; Lebenszyklus: Install → Activate → Fetch
- Web App Manifest: JSON-Datei (manifest.json) verlinkt im HTML-Head; Felder: name (App-Name), short_name (Homescreen-Icon-Label), icons (verschiedene Größen: 192×192, 512×512 px), start_url (Einstiegspunkt beim Öffnen vom Homescreen), display: standalone (kein Browser-Chrome sichtbar), background_color, theme_color; Voraussetzung für «Add to Home Screen»-Prompt; wichtig: Icons in WebP und PNG bereitstellen
- HTTPS-Pflicht: Service Worker laufen nur auf HTTPS (Sicherheitsanforderung); localhost als Ausnahme für Entwicklung; Kostenlose SSL-Zertifikate: Let's Encrypt; Hosting-Plattformen (Netlify, Vercel, GitHub Pages): HTTPS standardmäßig; ohne HTTPS: keine PWA-Funktionen möglich
- Lighthouse-Audit: Chrome DevTools → Lighthouse → PWA-Kategorie; prüft: Service Worker vorhanden, HTTPS, Manifest vollständig, Offline-Funktion, Meta Viewport, Icons; Score 0–100; PWA-Badge bei Erfüllung aller Kernkriterien; Google PageSpeed Insights nutzt ebenfalls Lighthouse; regelmäßiger Audit empfohlen nach Änderungen
PWA-Fähigkeiten und Plattform-Unterschiede
- Offline-Funktion: Service Worker cached Assets und API-Responses beim ersten Besuch; Cache-Storage: statische Dateien (HTML, CSS, JS, Bilder); IndexedDB: dynamische Daten (Nutzerdaten, Content); Offline-Fallback: eigene Offline-Seite statt Browser-Fehlermeldung; Background Sync: Formulardaten werden bei Wiederverbindung automatisch gesendet; besonders wertvoll für Regionen mit schlechter Konnektivität und für Nutzer in U-Bahn/Tunnel
- Push-Notifications (Android): Web Push Protocol (RFC 8030); Opt-in über Browser-Prompt («Website möchte Benachrichtigungen senden»); Opt-in-Rate: 5–15 % (niedriger als Native-App-Push, aber ohne App-Installation); Öffnungsrate: 15–25 % (ähnlich wie Native Push); Service: Firebase Cloud Messaging (FCM) als kostenloser Web-Push-Dienst; Personalisierung über Segmentierung möglich
- iOS-Unterstützung (Safari): Safari 11.1+ (iOS 11.3): Service Worker und Manifest-Grundunterstützung; Safari 16.4+ (iOS 16.4, März 2023): Web Push für PWAs auf Homescreen; iOS-Limitierungen: Push-Notifications nur für installierte PWAs (Add to Home Screen), kein automatischer Install-Prompt wie Android; Speicher: iOS begrenzt Service-Worker-Cache auf 50 MB; Safari-Updates = iOS-Updates: langsamere Adoption neuer Features; praktische Folge: Android PWAs deutlich mächtiger als iOS PWAs
- Android-Chrome-Vorteile: Automatischer «Add to Home Screen»-Prompt wenn PWA-Kriterien erfüllt; BeforeInstallPrompt-Event: Entwickler können Prompt-Zeitpunkt kontrollieren; Trusted Web Activity (TWA): PWA im Google Play Store publizierbar ohne Store-Einschränkungen; Web NFC, Web Bluetooth, File System Access API: Android Chrome bietet mehr Hardware-Zugriff als iOS Safari
PWA vs. Native App: Entscheidungshilfe
- PWA bevorzugen wenn: primär neue Nutzer über SEO oder Ads akquiriert werden sollen; kein Budget für separate iOS- und Android-Entwicklung; Inhalte crawlbar sein müssen (SEO-Anforderung); Nutzungsfrequenz niedrig bis mittel (unter wöchentlich); schnelle Time-to-Market entscheidend; keine App-Store-Provision (15–30 %) tragen wollen
- Native App bevorzugen wenn: tägliche Nutzung und hohe Retention angestrebt; Hardware-Zugriff nötig (Kamera ARKit, Bluetooth Low Energy, NFC auf iOS, Gyroscope für AR); In-App-Purchase-Ökosystem genutzt werden soll; App-Store-Discovery wichtig (ASO-Strategie); Gamification und Push-Engagement zentral; komplexe UI-Animationen und Performance-Anforderungen
- Hybride Strategie: PWA als Mobile-Web-Basis + Trusted Web Activity für Play-Store-Vertrieb (Android); separate native iOS-App für High-Value-Nutzer; Deep-Linking zwischen PWA und nativer App; E-Commerce-Beispiel: PWA für Neukunden-Akquisition + native App für Bestandskunden-Retention
- Marketing-Vorteile der PWA: SEO: alle Inhalte crawlbar, kein App-Store-Indexierungs-Problem; Teilen: URLs teilbar per Link (native App-Inhalte schwer teilbar); A/B-Testing: Standard-Web-Tools (Google Optimize, VWO) funktionieren; Analytics: GA4, Matomo laufen wie auf normaler Website; kein App-Store-Review-Risiko bei Kampagnen-Landing-Pages