Webanwendung entwickeln lassen: SPA, PWA oder klassisch?

Die Frage kommt fast immer zu spät. Ein Kunde hat schon ein Design, schon eine Featureliste, manchmal sogar schon ein Angebot von woanders. Und dann fällt das Wort SPA, jemand wirft PWA in den Raum, und plötzlich reden alle über Technik, die niemand am Tisch wirklich greifen kann. Wer eine Webanwendung entwickeln lassen will, entscheidet mit der Architektur über Ladezeiten, Sichtbarkeit bei Google und einen guten Teil der Kosten. Diese Entscheidung gehört an den Anfang, nicht ans Ende.

Es gibt grob drei Wege. Die klassische Multi-Page-Anwendung, bei der der Server für jede Seite frisches HTML ausliefert. Die Single Page Application, kurz SPA, die einmal lädt und danach alles im Browser per JavaScript nachzieht. Und die Progressive Web App, kurz PWA, die genau genommen keine eigene Architektur ist, sondern eine Schicht obendrauf, mit der sich eine Website wie eine installierte App verhält. Klingt nach Detail. Ist es nicht.

Was SPA, PWA und klassisch wirklich unterscheidet

Die klassische Variante ist der älteste Ansatz und immer noch der unaufgeregteste. Du klickst, der Server schickt eine komplette neue Seite, fertig. Jede Seite existiert als eigene URL mit eigenem HTML. Für Suchmaschinen ist das ideal, weil der Inhalt sofort da ist, ohne dass ein Browser erst Code ausführen muss. Der Preis: Bei jedem Klick gibt es kurz einen Moment Leere, bis die neue Seite steht.

Eine SPA dreht das um. Sie lädt beim ersten Aufruf ein größeres Paket JavaScript, und ab dann wechselt sie Inhalte, ohne neu zu laden. Das fühlt sich an wie eine Desktop-Anwendung im Browser. Gmail, Trello oder ein Buchungstool funktionieren so. Schnell in der Bedienung, aber mit einem Haken, über den viele Anbieter hinweggehen: Der erste Aufruf ist oft langsamer, und der Inhalt steht erst da, wenn der Browser das JavaScript abgearbeitet hat.

Eine PWA setzt auf einer dieser beiden Varianten auf. Über einen Service Worker und eine Manifest-Datei wird aus der Website etwas, das man auf dem Homescreen installieren kann, das offline funktioniert und das seit iOS 16.4 sogar auf dem iPhone Push-Benachrichtigungen schicken darf. Apple hat das im Frühjahr 2023 freigeschaltet, und das war ein größerer Schritt, als es klingt. Vorher war Web Push auf iPhones schlicht nicht möglich.

Warum SEO bei SPAs schnell zum Problem wird

Hier trennt sich die Spreu vom Weizen. Googlebot crawlt JavaScript-Seiten in zwei Wellen. In der ersten liest er das rohe HTML, schnell und oft. Erst in einer zweiten, deutlich späteren Welle rendert er die Seite in einer Chromium-Engine und führt das JavaScript aus. Diese zweite Welle kann nach Sekunden kommen. Oder nach Tagen. Manchmal nach Wochen, abhängig davon, wie wichtig Google deine Domain einschätzt.

Bei einer reinen SPA sieht Google in der ersten Welle oft eine fast leere Seite. Kein Text, keine Überschriften, keine internen Links. Wenn die Navigation auch noch erst per JavaScript entsteht, fehlt dem Crawler das Linkgerüst komplett, und die einzelnen Inhalte werden gar nicht erst gefunden. Wer auf organischen Traffic angewiesen ist, ein Magazin, ein Shop, eine öffentliche Produktseite, der baut sich mit einer naiven SPA ein echtes Problem.

Lösbar ist das, aber nicht umsonst. Server-Side Rendering oder Pre-Rendering über Frameworks wie Next.js, Nuxt oder SvelteKit liefern fertiges HTML aus und lassen die App danach im Browser übernehmen. Google empfiehlt diesen Weg ausdrücklich für Inhalte, die ranken sollen. Das kostet mehr Entwicklungsaufwand und mehr Serverleistung. Wer das einkalkuliert, fährt gut. Wer es überspringt, merkt es erst, wenn die Rankings ausbleiben, und dann ist die Architektur schon gebaut.

Für interne Tools ist das alles übrigens egal. Ein Kundenportal hinter dem Login muss bei Google nicht ranken. Da spielt die SPA ihre Stärke voll aus, und SEO ist schlicht kein Thema.

Was eine Webanwendung kostet

Pauschalpreise sind hier Unsinn, aber eine Größenordnung hilft. Eine einfache Webanwendung startet in Deutschland laut Anbieterangaben bei rund 3.000 Euro, etwa ein schlankes Portal mit ein paar Verwaltungsfunktionen. Der realistische Bereich für eine ernsthafte Geschäftsanwendung mit mehreren Nutzergruppen, Benachrichtigungen und einer ordentlichen Verwaltung liegt zwischen 10.000 und 30.000 Euro. Nach oben ist Luft, komplexe Plattformen mit Echtzeitdaten, Dokumentengenerierung und Mehrsprachigkeit knacken die 30.000 schnell.

Die Architektur verschiebt diese Zahlen. Eine SPA mit sauberem Server-Side Rendering und PWA-Funktionen ist aufwendiger als eine klassische Multi-Page-Seite mit demselben Funktionsumfang. Dafür kannst du dir mit einer ordentlichen PWA die separate native App fürs Smartphone oft sparen, und das ist der eigentliche Hebel beim Budget. Pinterest hat seine PWA gebaut, weil die mobile Website nur ein Prozent der Nutzer zu Anmeldungen brachte. Danach verbrachten die Leute 40 Prozent mehr Zeit auf der Seite und der Werbeumsatz stieg um 44 Prozent. Starbucks hat eine PWA, die 99 Prozent kleiner ist als die 148 Megabyte schwere native iOS-App, und hat damit die täglichen Web-Nutzer verdoppelt.

Was oft vergessen wird, sind die laufenden Kosten. Hosting, Wartung, Sicherheitsupdates. Eine SPA mit Server-Side Rendering braucht mehr Serverleistung als eine statisch ausgelieferte Seite. Das ist keine große Summe, aber es ist eine monatliche Summe, und sie gehört in die Rechnung. Software ist 2025 in Deutschland laut Bitkom um fast zehn Prozent auf 51 Milliarden Euro gewachsen, der Bedarf ist riesig. Das heißt aber nicht, dass jedes Budget jede Architektur trägt.

Wie du die richtige Wahl triffst

Fang nicht bei der Technik an, sondern bei der Frage, was die Anwendung tun soll. Drei Punkte bringen dich meistens schon ans Ziel.

Erstens: Muss der Inhalt bei Google ranken? Wenn ja, dann entweder klassisch bauen oder eine SPA mit Server-Side Rendering. Eine reine Client-SPA für eine öffentliche, SEO-relevante Seite ist ein Fehler, den du teuer bezahlst.

Zweitens: Ist es ein Tool oder eine Website? Hinter einem Login, mit viel Interaktion, vielen Formularen und Zuständen, da glänzt die SPA. Eine Seite, die vor allem Inhalte zeigt und gefunden werden soll, gehört eher in die klassische Webentwicklung oder wird als Hybrid gebaut, der pro Seite entscheidet, was sie braucht.

Drittens: Brauchen deine Nutzer eine App auf dem Handy? Wenn Offline-Nutzung, Homescreen-Symbol und Push-Benachrichtigungen wichtig sind, dann ist eine PWA fast immer günstiger und schneller umgesetzt als zwei native Apps für iOS und Android. Mit der Einschränkung, dass die Installation auf dem iPhone bis heute umständlich ist. Es gibt keinen automatischen Hinweis, der Nutzer muss die App von Hand über das Teilen-Menü zum Homescreen hinzufügen. Das musst du den Leuten erklären, sonst nutzt es keiner.

In der Praxis ist die Antwort heute selten ein reines Entweder-oder. Die meisten ernsthaften Projekte landen bei einem hybriden Ansatz: ein Framework, das öffentliche Seiten als fertiges HTML ausliefert und interaktive Bereiche als SPA betreibt, ergänzt um PWA-Funktionen dort, wo sie echten Nutzen bringen.

Häufige Fehler, die später wehtun

Der teuerste Fehler ist, die Architektur nach dem Framework auszusuchen, das der Entwickler gerade gut kennt. “Wir machen das in React als SPA” ist keine Entscheidung, sondern eine Gewohnheit. Wenn dann eine inhaltsgetriebene Seite ohne Server-Side Rendering live geht, fehlt der organische Traffic, und niemand versteht warum.

Der zweite Fehler ist der Glaube, eine PWA ersetze eine native App eins zu eins. Auf iOS gibt es bis heute Grenzen. Eingeschränkter Zugriff auf Bluetooth und USB, kein Eintrag im App Store, schwächere Offline-Fähigkeiten als bei nativen Apps. Für die meisten Geschäftsanwendungen reicht eine PWA locker. Für eine Anwendung, die tief in die Hardware greift, eben nicht. Wer das vorher nicht prüft, baut zweimal.

Und der dritte Fehler ist, die Frage nach SEO und mobiler Nutzung erst zu stellen, wenn alles fertig ist. Eine Architektur lässt sich später nur mit hohem Aufwand wechseln. Wer das unterschätzt, zahlt es meistens als komplette Neuentwicklung nach.

Worauf es ankommt

SPA, PWA oder klassisch ist keine Glaubensfrage, sondern hängt an drei Dingen: Sichtbarkeit bei Google, Grad der Interaktion und der Frage, ob es eine App aufs Handy braucht. Klär diese drei Punkte, bevor jemand eine Zeile Code schreibt, dann passt die Technik zum Ziel und nicht umgekehrt.

Wenn du gerade vor genau dieser Entscheidung stehst, lass uns kurz draufschauen, bevor du dich festlegst. In einer Fokus-Session sortieren wir, welche Architektur zu deinem Projekt und deinem Budget passt, und du gehst mit einer klaren Empfehlung raus. Wenn du schon weißt, dass du eine Webanwendung entwickeln lassen willst, schauen wir uns dein Vorhaben direkt im Detail an.