Leitfäden

„SPA vs. PWA“ ist eine der häufigsten Verwechslungen in der Front-End-Entwicklung, und der Grund ist einfach: Die beiden Begriffe sind überhaupt keine Gegensätze. Eine Single-Page-Application (SPA) beschreibt, wie eine Anwendung gebaut ist und navigiert, während eine Progressive Web App (PWA) beschreibt, was eine Anwendung für den Nutzer leisten kann. Sie gegeneinanderzustellen ist ein wenig so, als würde man „Schaltgetriebe oder Elektroauto“ fragen — du vergleichst zwei verschiedene Achsen, und eine App kann ohne Weiteres beides, eines oder keines von beiden sein.

Was eine SPA ist

Eine Single-Page-Application lädt ein einzelnes HTML-Dokument und schreibt dann die Seite im Browser neu, während du navigierst, statt bei jedem Klick eine frische Seite vom Server zu holen. Nach dem ersten Laden tauscht das JavaScript die relevanten Teile der Oberfläche aus und holt nur die Daten, die es braucht, üblicherweise als JSON von einer API. Das Ergebnis fühlt sich eher wie eine Desktop- oder Mobile-App an, mit sofortigen Übergängen und ohne vollständige Seitenneuladungen. React, Vue, Svelte und Angular existieren weitgehend, um dieses Modell praktikabel zu machen.

Was eine PWA ist

Eine Progressive Web App ist eine ganz andere Idee: Sie ist eine Website, die moderne Web-Standards nutzt, um sich eher wie eine installierte App zu verhalten. Die drei Säulen sind ein Web-App-Manifest (damit sie mit Icon und Namen zum Startbildschirm hinzugefügt werden kann), ein Service Worker (ein Skript, das Ressourcen cachen und offline ausliefern kann) und HTTPS (erforderlich für diese Fähigkeiten). Eine PWA kann Push-Benachrichtigungen senden, ohne Verbindung arbeiten und in einem eigenen Fenster starten — alles von einer normalen URL aus, ohne App-Store.

• SPA = Architektur (clientseitige Navigation, keine Neuladungen)
• PWA = Fähigkeiten (installierbar, offline, Push)
• Eine PWA ist oft eine SPA — aber keines erfordert das andere
• SSR ist eine eigene Achse (Rendering, kein App-Typ)
• Wähle nach dem Bedarf des Produkts und leg dann Funktionen drauf

Warum sie keine Gegensätze sind

Das ist der Kern der Verwechslung, den es sich zu klären lohnt: Die beiden schließen sich nicht gegenseitig aus. Eine PWA wird sehr oft als SPA gebaut, muss es aber nicht — du kannst einer klassischen Multi-Page-Site ein Manifest und einen Service Worker hinzufügen und sie so zu einer PWA machen. Ebenso sind viele SPAs überhaupt keine PWAs, weil sie nie Offline-Support oder Installierbarkeit ergänzen. Bei der SPA geht es um die Navigationsarchitektur; bei der PWA um die Auslieferung und die obendrauf gelegten Fähigkeiten.

Die Kompromisse einer SPA

Für sich genommen erkauft dir das SPA-Modell flüssige Interaktivität zu einem Preis. Sobald das Bundle geladen ist, sind Interaktionen schnell, weil die App Daten anfragt statt ganzer Dokumente. Aber das erste Laden ist schwerer — der Browser muss JavaScript herunterladen und ausführen, bevor er aussagekräftige Inhalte zeigt — und Suchmaschinen sehen möglicherweise eine leere Hülle, sofern du nicht serverseitig renderst. SPAs glänzen bei Dashboards, Editoren und app-artigen Produkten, weniger bei einfachen Content-Seiten.

Die Kompromisse einer PWA

Die Fähigkeiten einer PWA lösen ein anderes Problem: erneute Bindung und Robustheit. Offline-Support bedeutet, dass die App auch bei einer wackeligen Zugverbindung noch funktioniert; Installierbarkeit setzt ein Icon auf den Startbildschirm und entfernt die Browser-Leiste; Push-Benachrichtigungen holen Nutzer zurück. Die Kompromisse sind ebenfalls real — Service Worker bringen eine Caching-Komplexität mit, die bei unsorgfältiger Handhabung veraltete Inhalte ausliefern kann, und Apples Unterstützung unter iOS hinkt, bei aller deutlichen Verbesserung, Android stellenweise noch hinterher.

Wo SSR hineinpasst

Ein dritter Begriff platzt meist in diesen Vergleich: SSR, also serverseitiges Rendering. Es lohnt sich, ihn abzugrenzen, denn er ist noch eine weitere Achse — eine Rendering-Strategie, kein App-Typ. Meta-Frameworks wie Nuxt und Next.js rendern die erste Seite auf dem Server, damit Nutzer und Suchmaschinen sofort echten Inhalt erhalten, und hydrieren sie dann im Browser zu einer SPA. Du kannst SSR mit einer SPA kombinieren, und eine PWA kann ebenfalls SSR nutzen; keines dieser Labels schließt die anderen aus.

Wie man wählt

Wie wählst du also konkret? Geh von dem aus, was das Produkt braucht, nicht vom Akronym. Ist es hochgradig interaktiv und verhält sich wie Software, passt die SPA-Architektur. Würden Nutzer von Offline-Zugriff, Installierbarkeit oder Push profitieren, leg die PWA-Fähigkeiten obendrauf — es ist von Natur aus inkrementell, und genau das bedeutet „progressive“. Geht es auf der Seite überwiegend um Inhalte und ist SEO am wichtigsten, setze auf serverseitiges Rendering oder sogar auf einen klassischen Multi-Page-Ansatz und ergänze PWA-Funktionen nur dort, wo sie sich lohnen.

Das Fazit

Das ehrliche Fazit ist, dass „SPA vs. PWA“ die falsche Rahmung ist. Es sind komplementäre Schichten: Die eine entscheidet, wie deine App navigiert, die andere, was sie kann, sobald sie da ist. Die stärksten modernen Web-Apps kombinieren oft alle drei Ideen — eine SPA für die Interaktivität, serverseitiges Rendering für schnelles erstes Rendern und SEO sowie PWA-Funktionen für Offline und Installierbarkeit — bewusst gewählt statt als rivalisierende Lager behandelt.