Man kauft keinen teuren Kühlschrank nur für Milch. Der Kühlschrank funktioniert, aber nach ein paar Monaten merkt man: Die Milch bleibt auch in einer Kühlbox frisch. Genau das ist dem TanStack-Team mit React Server Components (RSC) passiert. Sie kehrten zu klassischem Server-Side Rendering (SSR) zurück.
Tanner Linsley, Kopf hinter TanStack, beschrieb den Wechsel auf dem offiziellen Blog. Eine pragmatische Entscheidung, basierend auf harten Daten, nicht auf Hype. Sie wirft eine Frage auf: Wann ist ein neues Werkzeug die richtige Wahl – und wann wird es zum Hindernis?
Der Anfang: RSC als Retter
Vor Monaten war tanstack.com ein RSC-Paradebeispiel. Die Seite war content-lastig – Blogposts, Docs, Codebeispiele. Problem: Jeder Seitenaufruf lud ein schweres Markdown- und Syntax-Highlighting-Paket in den Browser. Rund 1,1 MiB JavaScript pro Docs-Seite, davon 358 KiB für Shiki und Begleiter. Eine unnötige Last für den Browser.
RSC schien die Lösung. Statt den schweren Renderer zum Client zu schicken, rendert man Markdown und Highlighting auf dem Server, schickt fertiges HTML (Flight-Payload). Der Browser hat weniger Arbeit. Die Performance-Sprünge waren beeindruckend: Total Blocking Time fiel von 1.200 ms auf 260 ms, Transfergröße von 1.101 KiB auf 785 KiB. Lighthouse-Scores gingen hoch. RSC hielt sein Versprechen.
Die unerwartete Einsicht
Im Alltag zeigte sich die Komplexität. Linsley beschreibt, wie die Content-Pipeline immer mehr Schichten bekam: Markdown wurde zu JSX in server-only Dateien, JSX zu Flight-Payload, Route-Komponenten empfingen contentRsc – ein fast unkenntlicher Wert. Jede Änderung erforderte Wissen über Runtime-Grenzen, Bundler-Konfiguration, spezielle Dateien. Nicht unmöglich, aber unnötig aufwendig.
Der entscheidende Moment: Das Team entfernte Drittanbieter-Anzeigen von der Seite. Plötzlich war der größte Übeltäter nicht das Ad-Tracking, sondern der Content selbst. Die Frage: Brauchen wir wirklich 358 KiB für Syntax-Highlighting? Oder geht es einfacher?
Der Bau eines schlankeren Werkzeugs
Das Team entwickelte zwei eigene Pakete: @tanstack/markdown und @tanstack/highlight. Klein, spezifisch, auf die Anforderungen von tanstack.com zugeschnitten. Kein Generalistenwerkzeug, sondern Spezialwerkzeuge. Ergebnis: Statt 358 KiB wanderten nur noch etwa 27 KiB zum Client – kein Grund mehr für eine ganze RSC-Architektur.
Der Trade-Off wurde klar: RSC löste ein Abhängigkeitsproblem durch Architektur. Nachdem die Abhängigkeit schrumpfte, blieb die Architektur mit ihren Kosten: spezielle Routen, Flight-Serialisierung, Server-only-Komponenten, verzwickter Context.
Zurück zu SSR – und die Ergebnisse
Das Team entfernte die RSC-Content-Pipeline. Der Migrations-Commit 92b1c481 löschte oder benannte neun Dateien für RSC-spezifische Content-Rohre um, plus acht alte Rendering-Plugins. Insgesamt 555 Zeilen RSC-Code und 994 Zeilen alte Renderer flogen raus. Der Content-Pfad wurde einfach: Serverfunktionen geben Content-Daten zurück, eine Markdown-Komponente rendert lokal.
Die Performance auf den wichtigsten Routen:
- /blog/react-server-components: RSC: 76 Lighthouse, 139 ms TBT, 1.086 KiB / SSR: 67 Lighthouse, 66 ms TBT, 889 KiB
- /router/latest/docs/overview: RSC: 71 Lighthouse, 209 ms TBT, 1.017 KiB / SSR: 71 Lighthouse, 115 ms TBT, 836 KiB
Der Lighthouse-Score beim Blog ist etwas niedriger, aber Bytes und TBT sind besser. Der Renderer wiegt jetzt etwa 27 KiB – ein Bruchteil des alten Shiki-Stacks. Der Vorteil zeigt sich bei wiederholten Seitenaufrufen.
Warum sechs Seiten den Unterschied machen
Beim ersten Aufruf lädt SSR den Renderer einmal. Danach nur noch reine Daten (Markdown, Quelldaten) – nicht den gerenderten Komponentenbaum. RSC hingegen schickt bei jeder Navigation erneut ein serialisiertes Flight-Payload mit dem gesamten Server-Teil.
Lokale Tests: Für einen Blogpost sparte SSR 5,6 KiB pro Anfrage gegenüber RSC. Bei sechs Seiten pro Session (Durchschnitt auf tanstack.com) multipliziert sich das. Einmal 27 KiB für den Renderer zahlen, dann jedes Mal sparen – eine lohnende Wette. RSC verwandelte eine einmalige Client-Abhängigkeit in wiederkehrende serialisierte Ausgabe. Sinnvoll bei großer Abhängigkeit, nicht nach Verkleinerung.
Die Lektion: Wann ist RSC wirklich die richtige Wahl?
Linsley selbst sagt: RSC löst ein Problem, wenn die Server-Abhängigkeit riesig ist. Ein schwerer Markdown-Renderer, eine große Grafikbibliothek, ein komplexer Parser. Sobald die Abhängigkeit verkleinert ist, entfällt die Rechtfertigung für die Komplexität.
Erkenntnis: Tool-Entscheidungen basieren auf Messungen, nicht auf Trends. RSC ist kein Selbstzweck. Die TanStack-Geschichte zeigt: Nach dem ersten Erfolg lohnt es sich zu fragen: War das nötig? Wie sieht der Preis im Alltag aus?
Für viele Projekte ist RSC perfekt. Für content-lastige Seiten mit kontrollierten Abhängigkeiten ist klassisches SSR mit eigenen Paketen oft einfacher und schneller. Devise: Verstehe dein Problem, miss deine Lösung, und tausche den Kühlschrank gegen eine Kühlbox.
Quelle: tanstack.com
