SPA vs. Hypermedia: Performance unter realen Bedingungen

Gemessen im Februar 2026, erneut im Oktober 2026 · Lighthouse + Chrome DevTools Performance Profiling · Quellcode & Rohdaten →

Methodik: Die Vercel-Referenz-App als Massstab

Wir haben unsere eigene PHP/Datastar-Hypermedia-Implementierung mit dem Vercel AI SDK Chatbot verglichen, der Referenzimplementierung von Vercel für einen KI-Chat mit Next.js, an der rund 80 Leute mitgearbeitet haben.

Beide Anwendungen implementieren dieselben Kernfunktionen: KI-Streaming in Echtzeit, Chat-Verlauf, Dokument-Artefakte und Authentifizierung. Die Testbedingungen waren identisch: Chromium 154 mit Lighthouse 13.5 im Oktober (Chrome 144 im Februar), Slow-4G-Netzwerksimulation (1.6 Mbps, 150 ms RTT) und 4-fache CPU-Drosselung zur Simulation von Mittelklasse-Mobilgeräten. Die Lighthouse-Werte sind der Median aus drei Läufen.

Lighthouse-Scores: Die Kluft auf Mobilgeräten

Auf dem Desktop mit schnellen Verbindungen schneiden beide Architekturen vergleichbar gut ab. Die echten Unterschiede zeigen sich unter eingeschränkten Bedingungen, genau in der Umgebung, in der der Grossteil der weltweiten Nutzer unterwegs ist.

Desktop (ohne Drosselung)

Mobile (Slow 4G + 4× CPU-Drosselung)

Hier werden die Auswirkungen von Architekturentscheidungen sichtbar. Das JavaScript-Bundle, das auf einem schnellen Desktop kaum auffällt, wird zum kritischen Engpass, wenn das Netz langsam und die CPU eingeschränkt ist.

Die Total Blocking Time von 898 ms vs. 0 ms der SPA bedeutet, dass der Main-Thread fast eine volle Sekunde lang nur mit dem Parsen und Ausführen von JavaScript blockiert ist: eine Zeit, in der die Seite zwar sichtbar, aber nicht auf Eingaben reagiert. Die Hypermedia-Version eliminiert das Blockieren vollständig: ihr server-gerendertes HTML ist sofort nutzbar, sobald es ankommt.

Was über die Leitung geht

Die 27-fache Reduktion der übertragenen Bytes schlägt sich direkt in schnelleren Ladezeiten bei langsamen Verbindungen nieder. Bei 1.6 Mbps dauert das Herunterladen von 1.4 MB rund 7 Sekunden, bevor der Browser überhaupt mit dem Parsen beginnen kann. 51.8 KB dauern etwa eine Viertelsekunde.

Visueller Beweis: Wohin die CPU-Zeit geht

Performance-Profiling während tatsächlicher Seitenladevorgänge und Chat-Interaktionen zeigt, wie jede Architektur CPU-Ressourcen nutzt. Die Flamegraphen unten zeigen Chrome-DevTools-Performance-Traces unter identischen Bedingungen: Slow-4G-Netzwerkdrosselung und 4-fache CPU-Verlangsamung. Dieser Abschnitt zeigt die Messung vom Februar.

• Scripting: JavaScript-Ausführung
• Rendering: Style-/Layout-Berechnung
• Painting: Pixel auf dem Bildschirm
• System: Browser-Internas
• Loading: Netzwerkaktivität
• Idle: Verfügbar für Nutzereingaben
• Memory: JS-Heap (unteres Diagramm)

Vergleich beim Seitenladen

Schieberegler ziehen, um SPA (links) vs. Hypermedia (rechts) zu vergleichen

Der wichtigste visuelle Unterschied in den Flamegraphen: Die SPA zeigt hohe, dichte Stapel von JavaScript-Ausführung (gelbe Blöcke), die den Trace dominieren. Der Flamegraph von Hypermedia ist flach und spärlich: Der Grossteil der Zeit wird im Leerlauf oder mit nativem Browser-Rendering verbracht, nicht mit JavaScript-Ausführung. Hinweis: Scripting-Zeit und Main-Thread-Zeit stammen aus verschiedenen DevTools-Ansichten. Das Summary-Panel summiert sämtliche Script-Ausführungen über Threads hinweg (inkl. Workers), während die Main-Thread-Zeit die aggregierte Task-Dauer aus dem Activity-Tab ist. Beide überschneiden sich, decken aber nicht exakt denselben Scope ab, weshalb Scripting höher erscheinen kann als Main-Thread-Zeit.

Die höhere DOM-Knotenanzahl bei Hypermedia (963 vs. 326) spiegelt server-gerenderten Inhalt wider, der sofort sichtbar ist. Die SPA startet mit einem minimalen DOM und baut es clientseitig durch Hydration auf, weshalb sie trotz weniger Knoten 5.9× mehr Event Listener hat.

Chat-Antwort-Vergleich (Streaming)

Schieberegler ziehen, um SPA (links) vs. Hypermedia (rechts) zu vergleichen

Beim Streaming verbringt die SPA über 4× mehr Zeit mit JavaScript-Ausführung als die Hypermedia-Version (10’500 ms vs. 2’485 ms). Hypermedia kompensiert mit mehr Rendering- und Painting-Zeit, weil Datastar das echte DOM bei jedem eingehenden SSE-Chunk patcht, anstatt Updates in einem virtuellen DOM zu puffern. Der native HTML-Parser des Browsers übernimmt die Hauptarbeit, was als Rendering-Kosten statt Scripting-Kosten erscheint. Insgesamt schliesst Hypermedia den vollständigen Chat-Response-Zyklus 37% schneller ab (12’500 ms vs. 19’686 ms).

¹ V8 Node Allocs zählt alle Knoten im V8-Heap, angehängte und getrennte (ausstehende GC). Datastar ersetzt DOM-Patches bei jedem SSE-Event und erzeugt verwaiste Knoten, die sich bis zur Garbage Collection ansammeln; das Live-DOM nach dem Streaming ist ~400 bis 600 Knoten. React reconciliert meist In-place, sodass kaum getrennte Knoten entstehen (+428 vs. +31’395). Diese Metrik spiegelt GC-Druck, nicht Live-DOM-Grösse, wider.

Streaming-Effizienz: SSE-Kompression

KI-Chat in Echtzeit basiert auf Server-Sent Events (SSE) für Token-für-Token-Streaming. Die beiden Architekturen unterscheiden sich nicht nur bei der Kompression, sondern auch beim grundlegenden Verbindungsmodell: Hypermedia hält einen einzigen dauerhaften SSE-Stream für die gesamte Session offen, während die SPA für jede Nachrichtenrunde einen neuen Streaming-POST öffnet. Dieser Unterschied summiert sich stark über ein Gespräch: Nach 10 Runden erreicht Brotli auf einem dauerhaften Stream ein 58.5-faches Kompressionsverhältnis: Aus einem 29-fachen Rohdaten-Nachteil wird ein 2-facher Übertragungsvorteil. Die Zahlen in diesem Abschnitt stammen aus der Messung vom Februar.

Einzelne Runde (Claude 4.5 Haiku, gleicher Prompt)

Gespräch über mehrere Runden (10 Runden, identische Prompts)

58.5× Brotli-Kompressionsverhältnis nach 10 Runden auf einem dauerhaften SSE-Stream

Es lohnt sich, ehrlich zu sein, was unsere PHP-Implementierung im Februar tatsächlich tat: Jedes Mal, wenn die KI ein neues Wort ausgab, wurde das gesamte Nachrichten-HTML-Fragment von vorne gestreamt, nicht nur das neue Token. Jeder Chunk ersetzte den vorherigen vollständig. Das war eine bewusste Einfachheitsentscheidung, keine Datastar-Anforderung: den naiven Ansatz wählen, bis es einen Grund gibt, es anders zu machen. Das erklärt das 29-fache Rohdaten-Gefälle. Trotz dieser selbst auferlegten Ineffizienz schlug die Kombination aus Brotli auf einer dauerhaften Verbindung die SPA über 10 Runden. Die Kompression glich mehr aus, als die naive Implementierung kostete.

Seit dem Umstieg auf php-via schickt die App weiterhin das ganze Fragment, aber höchstens 20-mal pro Sekunde statt bei jedem Token. Zehn Runden mit einer Antwort von 1’091 Zeichen kosten jetzt 34.5 KB über die Leitung (2.5 MB vor der Kompression); nach der ersten Runde braucht jede weitere etwa 2 KB.

Der Vorteil bei einer einzelnen Runde (2.4×) ist bereits vorhanden: Brotlis 18.7-faches Kompressionsverhältnis verwandelt einen 7.8-fachen Rohdaten-Nachteil in einen Nettogewinn. Der Vorteil über mehrere Runden wächst weiter: Ein dauerhafter Stream lässt Brotli alle Runden gemeinsam komprimieren und nutzt die rundenübergreifende Wiederholung im Chat-HTML, das mit wachsendem Gespräch zunimmt. Nach 10 Runden überträgt Hypermedia halb so viele Daten wie die SPA, selbst ausgehend von einer Implementierung, die vor der Kompression 29× mehr Bandbreite verschwendet.

² Next.js Streaming-POST-Antworten (/chat) haben keinen Content-Encoding-Header. Das Aktivieren von Komprimierungs-Middleware auf der Streaming-Route würde diese Lücke teilweise schliessen, aber der Overhead pro Verbindungsaufbau und die Unfähigkeit, ein Brotli-Wörterbuch über Runden hinweg zu teilen, würden bestehen bleiben.

Codebase- & Betriebskomplexität

Weniger Abhängigkeiten bedeuten eine kleinere Angriffsfläche, einfachere Sicherheitsaudits und weniger Breaking Changes beim Upgraden. Die 155-fache Reduktion des Produktions-Speicherplatzes führt auch zu schnelleren CI/CD-Pipelines und einfacheren Container-Images.

Die Wirtschaftlichkeit der Einfachheit

Technische Metriken sind interessant, aber was bedeuten sie für das Business? Architekturentscheidungen wirken sich über die Zeit aus und beeinflussen nicht nur die Performance, sondern auch die Entwicklungsgeschwindigkeit, Betriebskosten und Teamproduktivität.

Features vs. Wartung: Wohin geht die Zeit?

Überlegen Sie, was 592 Produktionsabhängigkeiten in der Praxis bedeuten. Jede Abhängigkeit ist eine potenzielle Quelle für Sicherheitslücken, die gepatcht werden müssen, Breaking Changes, die berücksichtigt werden müssen, und Kompatibilitätsprobleme, die debuggt werden müssen. Mit den schnellen Release-Zyklen im JavaScript-Ökosystem fliesst ein erheblicher Teil der Entwicklungszeit in die Pflege des Abhängigkeitsbaums statt ins Feature-Building.

Die versteckten Kosten der Komplexität

Komplexe Architekturen verlangsamen nicht nur die Anwendung, sondern auch das Team. Jede Architekturschicht erhöht die kognitive Last: Entwickler müssen Reacts Reconciliation, Next.js Rendering-Modi, das Vercel-Deployment-Modell und die Interaktion zwischen Client- und Server-State verstehen. Dieses Wissen braucht Zeit zum Aufbau und zur Pflege.

Im Gegensatz dazu hat eine server-autoritäre Hypermedia-Architektur eine einzige Quelle der Wahrheit (der Server), einen Rendering-Ort (der Server) und ein Deployment-Ziel (ein einfacher Prozess). Neue Teammitglieder werden schneller produktiv, und Debugging folgt einem einfachen Request-Response-Modell, statt State durch mehrere Schichten zu verfolgen.

Wann sich Einfachheit auszahlt

Das wirtschaftliche Argument für reduzierte Komplexität ist am stärksten dort, wo Zeit und Geld begrenzt sind, also in den meisten Projekten. Ein kleines Team ohne eigenen DevOps-Engineer oder Frontend-Spezialisten kann es sich schlicht nicht leisten, einen 592-Abhängigkeiten-Graph zu betreuen. Wenn ein transitives Paket ein Breaking Change einführt, ist das keine abstrakte Unannehmlichkeit; es ist ein halber Tag ungeplanter Arbeit, der ein Feature verdrängt. Je schlanker der Abhängigkeitsbaum, desto seltener passiert das.

Bei Anwendungen, die eher Jahre als Monate laufen sollen, wird diese Dynamik noch ausgeprägter. Initiale Entwicklungskosten sind eine Einmalzahlung, aber Wartung kumuliert sich unbegrenzt. Jedes Major-Framework-Upgrade, jede veraltete API, jede Verschiebung im JavaScript-Ökosystem kommt zum laufenden Gesamtaufwand hinzu. Weniger Abhängigkeiten und ein einfacheres mentales Modell halten diese Kosten beherrschbar, und institutionelles Wissen bleibt länger relevant.

Die Hosting-Wirtschaftlichkeit folgt derselben Logik. Nutzungsbasierte Preisgestaltung fängt zwar eine moderate Traffic-Spitze auf, bringt aber eine Abrechnungsüberraschung mit sich, die eine ungeplante Architekturüberprüfung erzwingt. Ein planbarer VPS für 20 $/Jahr tut das nicht. Die Kosten sind im Voraus bekannt, skalieren mit dem Team-Budget und halten den Fokus auf dem Produkt statt auf Cloud-Spending-Dashboards.

Schliesslich steht das Publikum selbst im Mittelpunkt. Die vollständige Eliminierung der Blocking Time (0 ms vs. 898 ms) und die 8.3-fache Verbesserung der Time to Interactive sind keine Benchmark-Kuriositäten: Sie entscheiden darüber, ob ein Nutzer auf einem Mittelklasse-Smartphone mit instabiler Verbindung das Produkt tatsächlich nutzen kann oder es in den ersten zehn Sekunden abbricht.

Einschränkungen & Vorbehalte

Wann was wählen

Architekturentscheidungen sollten von Anforderungen getrieben werden, nicht von Trends. Hier ist ein Rahmen zum Nachdenken über die Abwägungen:

Viele Anwendungen brauchen die Komplexität einer vollständigen SPA nicht. Die Frage ist nicht «was ist besser», sondern «welche Abwägungen passen zu meinen Rahmenbedingungen».

Zusammenfassung

Hypermedia gewinnt alle 9 gemessenen Kategorien eindeutig.

Diese Ergebnisse bedeuten nicht, dass SPAs «schlecht» sind oder dass jede Anwendung Hypermedia nutzen sollte. Sie zeigen, dass die Standardwahl einer SPA-Architektur reale Kosten trägt, die unter eingeschränkten Bedingungen erheblich werden, und dass Alternativen existieren.

Rohdaten: GitHub-Repository
Alle Benchmark-Daten, Lighthouse-Reports und Chrome-DevTools-Traces stehen zur unabhängigen Verifizierung zur Verfügung.