Single Page Application (SPA): Definition und Abwägungen

Was ist eine Single Page Application (SPA)?

Eine Single Page Application (SPA) lädt ein einziges Webdokument und aktualisiert dessen Inhalt anschließend per JavaScript, meist indem sie Daten von einer API holt, statt bei jedem Klick eine neue HTML-Seite vom Server anzufordern. Die Adressleiste ändert sich trotzdem und die Zurück-Taste funktioniert, weil die App die URL selbst verwaltet. MDN definiert es genauso und nennt die Kosten: SEO, Zustandsverwaltung, Navigation und Performance-Monitoring sind aufwendiger als bei einer klassischen Website mit mehreren Seiten.

So funktioniert eine SPA

1. Der Browser fordert die Seite an und der Server liefert eine kleine HTML-Hülle plus Verweise auf JavaScript-Bundles.
2. Der Browser lädt und führt die Bundles aus, und das Framework rendert die erste Ansicht im Browser. Das ist Client-Side Rendering.
3. Ein Klick auf einen Link wird von einem clientseitigen Router abgefangen, der die URL über die History API aktualisiert und die nächste Ansicht rendert, ohne ein neues Dokument anzufordern.
4. Jede Ansicht holt die benötigten Daten von Ihrem Backend, meist als JSON über HTTP.

Der erste Aufruf bezahlt also das Laden und Ausführen der App, jede weitere Navigation ist nur ein API-Aufruf plus Rendering.

SPA im Vergleich zur Multi-Page-Anwendung (MPA)

Die Grenze ist heute fließend. Frameworks wie Next.js rendern zuerst auf dem Server und werden im Browser per Hydration zur SPA, sodass eine Website beides haben kann.

SPAs und SEO

Google rendert JavaScript mit einem Headless-Chromium, aber in einem eigenen Schritt nach dem Crawling, und kann nur Links verfolgen, die echte <a href>-Elemente sind. Die JavaScript-SEO-Grundlagen von Google nennen Server-Side Rendering oder Prerendering weiterhin sinnvoll, weil es für Nutzer schneller ist und nicht jeder Crawler JavaScript ausführt. Drei praktische Punkte aus diesem Leitfaden:

• Verwenden Sie echte Pfade mit der History API, keine #/fragment-Routen.
• Eine clientseitig geroutete App kann für eine fehlende Seite nicht von allein einen echten 404-Status senden. Leiten Sie auf eine URL um, die 404 liefert, oder setzen Sie ein noindex-Robots-Tag, damit fehlende Seiten nicht als Soft-404 indexiert werden.
• Blockieren Sie Ihre JavaScript-Dateien nicht in der robots.txt.

Beispiel

Ein Projektmanagement-Tool ist eine typische SPA. Nach dem Login öffnet der Nutzer ein Board, zieht eine Karte und bearbeitet einen Kommentar, und jede Aktion ruft eine API auf, ohne die Seite neu zu laden. Die Marketing-Website desselben Produkts ist ein schlechter SPA-Kandidat: Sie braucht schnellen ersten Seitenaufbau und crawlbaren Text und wird besser als statisches oder serverseitig gerendertes HTML ausgeliefert.

Häufige Fehler

• Ein riesiges Bundle. Wer alle Routen vorab ausliefert, verzögert die erste Ansicht. Teilen Sie den Code nach Routen auf und laden Sie schwere Komponenten per Lazy Loading nach.
• Marketingseiten als reine SPA. Crawler und langsame Geräte bekommen zuerst eine leere Hülle.
• Kaputte History. Ansichten ohne eigene URL lassen Zurück-Taste, Lesezeichen und Teilen scheitern.
• Keine Lade- und Fehlerzustände. Ein leerer Bildschirm beim Laden wirkt defekt. Nutzen Sie Skeletons und Error Boundaries, damit eine fehlerhafte Komponente nicht die ganze App lahmlegt.
• Nur den ersten Aufruf messen. In einer SPA passiert der Großteil der Nutzung nach der Navigation, was ein einmaliger Seitentest nicht zeigt.

Testen und Überwachen einer SPA

Eine SPA verlagert Arbeit in den Browser und macht Ihr Backend zur API, also sollten Sie beide Hälften testen.

• Rendergeschwindigkeit: Verfolgen Sie Largest Contentful Paint und die anderen Core Web Vitals. Das Page-Speed-Monitoring von LoadFocus führt Lighthouse regelmäßig von Cloud-Standorten aus, und Real User Monitoring zeigt, was Besucher bei clientseitigen Navigationen tatsächlich erleben.
• API-Kapazität: Jede Ansicht ist ein API-Aufruf, ein Verkehrsanstieg trifft also Ihr Backend. Die Lasttests von LoadFocus führen JMeter- und k6-Skripte aus mehr als 25 Cloud-Regionen aus. Diese Werkzeuge arbeiten auf Protokollebene und führen Ihr Frontend-JavaScript nicht aus, sie messen also die APIs, die die SPA aufruft, nicht das Rendering im Browser.

Eine Schritt-für-Schritt-Anleitung finden Sie im Beitrag Lasttests für Single Page Applications optimieren (auf Englisch).

Häufige Fragen: Single Page Application

Sind SPAs schlecht für SEO?

Nicht per Definition, aber eine rein clientseitig gerenderte SPA liefert Crawlern eine leere Hülle, bis JavaScript läuft. Server-Side Rendering oder Prerendering, echte URLs und korrekte Statuscodes beseitigen das meiste Risiko.

Indexiert Google SPAs?

Ja. Google führt vor der Indexierung JavaScript mit einem Headless-Chromium aus. Das Rendering ist ein eigener Schritt, daher sind Inhalte, die schnell indexiert werden sollen, im ursprünglichen HTML sicherer.

Was ist der Unterschied zwischen SPA und Client-Side Rendering?

Client-Side Rendering beschreibt, wie Inhalte gezeichnet werden: im Browser per JavaScript. Eine SPA ist ein Anwendungsstil mit einem Dokument und clientseitiger Navigation. Die meisten SPAs nutzen Client-Side Rendering, aber auch eine App, die zuerst auf dem Server rendert und dann die Navigation im Browser übernimmt, ist eine SPA.

Was ist der Unterschied zwischen SPA und PWA?

Eine Progressive Web App ergänzt eine Web-App um Installierbarkeit, Offline-Unterstützung und Service Worker. Viele PWAs sind SPAs, aber eine SPA ist nicht automatisch eine PWA.

Wann sollte ich keine SPA bauen?

Für inhaltsgetriebene Websites wie Blogs, Dokumentation und Marketingseiten, bei denen schneller Seitenaufbau und Sichtbarkeit in der Suche am wichtigsten sind. Statische oder serverseitig gerenderte Seiten passen dort besser.