Anwendungsaufbau im Browser

Was ist eine Single-Page-Application?

SPA, Einseitenanwendung

Eine Single-Page-Application ist eine Webanwendung, die ein einziges HTML-Dokument lädt und danach alle Ansichtswechsel im Browser selbst erledigt, wobei nur noch Daten über Schnittstellen nachgeladen werden.

Ein mehrstufiges Formular, das Zwischenstände behalten soll, ohne bei jedem Schritt neu zu laden, ist der typische Fall für diesen Aufbau.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Lädt: Ein HTML-Dokument, danach nur noch Daten
Übernimmt selbst: Routing, Verlauf und Fehlerseiten
Braucht: Server-Fallback auf das eine Dokument
Verwechselt mit: Progressive Web App

Was beim Klick wirklich passiert

Bei einer klassischen Website fordert jeder Klick eine neue Seite an, der Browser wirft die alte weg und baut alles neu auf. In einer SPA fängt ein Router im JavaScript den Klick ab, ändert über die History-API die Adresszeile und tauscht nur den Teil der Oberfläche aus, der sich unterscheidet.

Deshalb bleibt der Zustand erhalten: eine halb ausgefüllte Eingabe, die Scrollposition einer Liste, eine offene Seitenleiste. Und deshalb wirkt der Wechsel sofort, denn statt eines vollständigen Dokuments wird oft nur eine kleine JSON-Antwort geholt, manchmal gar nichts, weil die Daten schon im Speicher liegen.

Was du dafür selbst übernimmst

Alles, was der Browser sonst mitbringt, wird zu deiner Aufgabe. Der Zurück-Knopf muss vom Router bedient werden, sonst landet man versehentlich außerhalb der Anwendung. Der Ladezustand braucht eine sichtbare Rückmeldung, weil die Adresszeile keinen Fortschritt mehr anzeigt. Und Fehler beim Nachladen musst du selbst auffangen, denn es gibt keine Fehlerseite des Servers mehr.

Dazu kommt die Barrierefreiheit: Nach einem Ansichtswechsel bleibt der Fokus dort, wo er war, und Screenreader bekommen nichts mit. Üblich ist deshalb, den Fokus auf die neue Überschrift zu setzen und den Wechsel über einen Live-Bereich anzukündigen.

Und das Bündel wächst. Ohne Aufteilung nach Route lädt jemand, der nur die Anmeldeseite sehen will, den Code der gesamten Anwendung mit. Lazy Loading pro Route ist deshalb kein Feinschliff, sondern gehört von Anfang an dazu.

Wann eine SPA passt und wann nicht

Für Anwendungen mit vielen Interaktionen hinter einer Anmeldung ist das Modell stark: ein Planungswerkzeug, ein Ticketsystem, eine Verwaltungsoberfläche. Dort zählt, dass Zustand bestehen bleibt und Wechsel ohne Neuaufbau laufen, und Suchmaschinen spielen keine Rolle.

Für inhaltsgetriebene Seiten ist sie oft zu viel. Ein Fachtext oder ein Katalog braucht schnelle erste Anzeige und indexierbares HTML, beides bekommst du serverseitig einfacher. Die Frameworks haben darauf reagiert und mischen heute: Der Rahmen kommt vom Server, einzelne Bereiche verhalten sich wie eine SPA.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Nicht verwechseln

Single-Page-Application und was oft damit gleichgesetzt wird

Single-Page-Application gegen Multi-Page-Application

Dort liefert der Server pro Klick ein neues Dokument. Das ist einfacher zu bauen und zu betreiben, und mit Techniken wie Turbo oder htmx fühlt es sich sehr ähnlich an, ohne dass du Routing und Zustand selbst verwaltest.

Single-Page-Application gegen Progressive Web App

Eine PWA ist über einen Service Worker installierbar und offlinefähig. Das lässt sich mit einer SPA kombinieren, ist aber unabhängig davon: Auch eine klassische Seite kann eine PWA sein.

Single-Page-Application gegen Server-Side Rendering

SSR beschreibt, wo das HTML entsteht, SPA beschreibt, wer die Navigation übernimmt. Eine Anwendung kann serverseitig gerendert werden und sich danach trotzdem wie eine SPA verhalten.

KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

In der Praxis

Alles, was der Browser bisher geschenkt hat, baust du nach

Beim Klick auf einen Link wechselt keine Seite, sondern die Anwendung tauscht Inhalte aus und schreibt die neue Adresse in den Verlauf. Damit liegt der Zurück-Button in deiner Verantwortung, ebenso die Scrollposition beim Zurückspringen und die Frage, was passiert, wenn jemand eine tiefe Adresse direkt aufruft oder neu lädt.

Weniger offensichtlich ist die Bedienung ohne Maus. Nach einem Ansichtswechsel bleibt der Tastaturfokus dort, wo er vorher war, und wer mit einer Sprachausgabe arbeitet, bekommt nicht mit, dass sich überhaupt etwas geändert hat. Seitentitel und Fokus müssen nach jedem Wechsel gesetzt werden, sonst ist die Anwendung für einen Teil der Belegschaft unbrauchbar.

Der dritte Punkt ist das Gewicht. Alles, was die Anwendung jemals braucht, kommt zunächst in einem Paket, und das wächst mit jedem neuen Bildschirm. Ohne Aufteilung nach Route lädt jemand, der nur ein Formular ausfüllen will, die Auswertungen gleich mit herunter.

Single-Page-Application lernen

Routing, Zustand und das Nachladen von Daten hängen enger zusammen, als es zunächst aussieht, und genau daran arbeiten die JavaScript-Trainings für Entwicklerteams .

Wenn du das Modell mit serverseitig erzeugten Seiten vergleichen willst, hilft der Überblick in den Kursen rund um Frontend-Architektur .

Kurse, die Single-Page-Application behandeln

Häufige Fragen

Sind SPAs schlecht für die Sichtbarkeit in Suchmaschinen?

Sie machen es schwerer. Wenn die Inhalte erst durch JavaScript entstehen, hängt die Indexierung davon ab, dass der Crawler das ausführt, was Zeit kostet und nicht garantiert ist. Für Inhalte, die gefunden werden sollen, lieferst du besser fertiges HTML aus.

Brauche ich für eine SPA eine Zustandsbibliothek?

Erst wenn Daten an mehreren, weit auseinanderliegenden Stellen gebraucht werden. Vieles, was früher in einen globalen Speicher wanderte, ist in Wahrheit zwischengespeicherte Serverantwort und gehört in eine Datenbibliothek, nicht in den Anwendungszustand.

Wie halte ich die Anmeldung sicher?

Ein Token im Local Storage ist über eingeschleustes JavaScript auslesbar. Robuster ist ein Cookie mit HttpOnly und SameSite, das der Browser automatisch mitschickt und das JavaScript gar nicht erst sieht.

Persönlich für dich da