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.

Einzelne Runde (Claude 4.5 Haiku, gleicher Prompt)

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

Es lohnt sich, ehrlich zu sein, was unsere PHP-Implementierung tatsächlich tut: Jedes Mal, wenn die KI ein neues Wort ausgibt, wird das gesamte Nachrichten-HTML-Fragment von vorne gestreamt – nicht nur das neue Token. Jeder Chunk ersetzt den vorherigen vollständig. Das ist 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 schlägt die Kombination aus Brotli auf einer dauerhaften Verbindung die SPA über 10 Runden. Die Kompression kompensiert mehr als die naive Implementierung kostet.

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.

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?

Überleg, was 799 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 – sie verlangsamen 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 den meisten Projekten. Ein kleines Team ohne eigenen DevOps-Engineer oder Frontend-Spezialisten kann es sich schlicht nicht leisten, einen 799-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. 780 ms) und die 7.5-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.

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».