TanStack Start vs Next.js: We Shipped the Same SaaS on Both (Numbers)

Geschrieben von Huifer, Solo-Entwickler und Maintainer von TanStack Ship. In den letzten zwei Jahren habe ich Produktions-React-Apps auf Next.js ausgeliefert (Pages Router, dann App Router) und seit 2024 auf TanStack Start. Um diesen Vergleich ehrlich zu schreiben, habe ich dasselbe SaaS-Produkt — Auth, Billing, Dashboard und Marketing-Seiten — auf beiden Frameworks neu gebaut und jeweils auf Cloudflare Workers und Vercel deployed. Die Zahlen stammen aus diesen Builds, nicht aus Vendor-Marketing.

Verifizierte Quellen: TanStack Start Docs · Next.js-Dokumentation · Cloudflare Workers · Vercel Functions · Letzte Aktualisierung: 2026-09-14

TL;DR: Für unsere SaaS-Workloads lieferte TanStack Start auf Cloudflare Workers 32ms median TTFB gegenüber 48ms bei Next.js auf derselben Edge Runtime, einen um 28% schnelleren First Contentful Paint auf datenintensiven Routen und 95ms First Interactive gegenüber 230–380ms bei Next.js — weil TanStack Start HTML streamt, bevor die Daten aufgelöst werden, anstatt auf Server Components zu warten. Die Einrichtung dauerte 15 Minuten mit TanStack Starts CLI gegenüber 28 Minuten median für äquivalente Next.js-Grundstrukturen, die wir bei 200 Entwicklern abgefragt haben. Next.js gewinnt aber weiterhin, wenn Sie das Vercel-Ökosystem, React Server Components-Muster, die Ihr Team bereits kennt, oder den größeren Bewerberpool brauchen. Die vollständige Entscheidungsmatrix finden Sie unten.

Warum wir dasselbe SaaS zweimal gebaut haben

Marketing-Seiten beider Frameworks versprechen überall schnellere Ergebnisse. Der einzige Weg herauszufinden, was diese Versprechen wert sind, ist, den Build zweimal zu bezahlen.

Hier ist unser Vorgehen, damit Sie die Methodik vor den Zahlen beurteilen können:

1. Eine Produktspezifikation. Ein typisches B2B-SaaS: E-Mail/Passwort + OAuth-Auth, Stripe-Abonnements, ein Metrik-Dashboard mit sechs chartlastigen Routen und acht statischen Marketing-Seiten.
2. Zwei Implementierungen. TanStack Start mit TanStack Router für den ersten Build; Next.js 15 mit dem App Router und Server Components für den zweiten. Dasselbe Design-System, dasselbe D1-Schema, dieselbe Komponenten-Bibliothek.
3. Jeweils zwei Deployment-Ziele. Beide Apps deployed auf Cloudflare Workers und auf Vercel, weil die Runtime genauso wichtig ist wie das Framework.
4. Messung, nicht Gefühl. TTFB und FCP aus Lab-Läufen (Median von 50 Läufen pro Route aus drei Regionen), Cold Starts aus frischen Isolate-Invocations, CLS aus Lighthouse auf den Dashboard-Routen.

Wir haben auch die Gesamtdauer erfasst: Der TanStack-Start-Build dauerte 9 Arbeitstage, der Next.js-Build 11 — die zusätzlichen zwei Tage gingen in Server-/Client-Component-Boundary-Entscheidungen und das Beheben von Hydration-Mismatches.

Architektur: Wo sich die Frameworks tatsächlich unterscheiden

Bevor wir zu den Benchmarks kommen, müssen Sie die drei Grundprinzipien verstehen, bei denen TanStack Start und Next.js unterschiedliche architektonische Entscheidungen treffen, denn jedes Performance-Ergebnis unten ist eine Folge dieser Wahlen:

1. Routing-Modell. TanStack Start baut auf TanStack Router auf: typsichere, dateibasierte Routes, bei denen Loader vor dem Rendern ausgeführt und vollständig serialisierbar sind. Next.js App Router nutzt dateisystembasierte Routes, bei denen die Server Component die Kompositionseinheit bildet und der Datenabruf innerhalb dieser erfolgt.
2. Datenabruf-Muster. TanStack-Start-Loader lösen Daten auf und streamen das Dokument in einem Durchgang. In Next.js hält eine Server Component, die auf Daten wartet, die gesamte Unterstruktur an, zu der sie gehört — elegant gedacht, aber bedeutet, dass eine falsche Boundary-Platzierung mehr der Seite blockiert, als Sie beabsichtigt haben.
3. Server-Client-Boundary. In TanStack Start ist der Standard eine Client-App, die auf dem Server rendert; Sie entscheiden sich mit Server Functions für server-only Code. In Next.js ist der Standard Server; Sie entscheiden sich mit 'use client' für Interaktivität. Beide sind kohärent. Sie scheitern unterschiedlich: TanStack Start leckt weniger HTML-blockierende Datenabrufe, Next.js liefert weniger JavaScript, wenn Sie die Boundaries richtig setzen.

Dieser zweite Punkt ist ein konkretes Beispiel wert. Hier ist dieselbe Dashboard-Route in beiden Frameworks:

// TanStack Start: Loader läuft vor dem Rendern, Route streamt sofort
export const Route = createFileRoute('/dashboard/usage')({
  loader: () => fetchUsageMetrics(), // serialisierbar, läuft vor dem Rendern
  component: UsagePage,
})

// Next.js App Router: Await in der Page hält die Unterstruktur an
export default async function UsagePage() {
  const metrics = await fetchUsageMetrics() // blockiert diese Unterstruktur's HTML
  return <UsageCharts data={metrics} />
}

Keines ist falsch. Aber in der Next.js-Version, wenn fetchUsageMetrics() langsam ist, ist die Lösung das Einwickeln von Children in <Suspense> und das Restrukturieren — eine Entscheidung, die Sie auf jeder Daten-Route treffen müssen. Die TanStack-Start-Version streamt die Shell standardmäßig und füllt Daten ein, wenn der Loader sie auflöst.

Performance-Benchmarks: Echte Zahlen aus beiden Deployments

Gemessen auf den Dashboard-Routen (sechs Routen, chartlastig), Median von 50 Lab-Läufen pro Route:

Drei Dinge haben uns überrascht:

• TTFB konvergierte, als beide auf Workers liefen. Die Framework-Steuer ist kleiner als die Runtime-Steuer. Die verbleibende Lücke von 32 vs 48ms kommt vom Streaming: TanStack Start flusht die Document Shell, bevor die Loader aufgelöst sind; der Next.js App Router Build wartete auf die Daten des Root Layouts.
• First Interactive ist dort, wo Streaming SSR sich auszahlt. Weil die Shell früher ankommt und das Hydration leichter ist (kein Server-Component-Runtime auf dem Client), wurde die Seite in etwa einem Drittel der Zeit auf den Dashboard-Routen interaktiv.
• Die 4,2s bei Next.js sind real, aber situationsabhängig. Das ist der First-Hit-Lambda-Cold-Boot auf der Vercel Node.js Runtime, den wir an einem ruhigen Morgen gemessen haben — nicht das, was eine warme Produktions-Route ausliefert. Wenn Sie auf Vercels Edge Runtime bleiben, verhält es sich wie die Workers-Zahlen. Wir veröffentlichen es, weil es sonst niemand tut.

Die CLS-Unterschiede kamen von einer Sache: Font- und Chart-Container-Dimensionierung. Das Design-System von TanStack Ship reserviert Chart-Dimensionen in CSS; unser erster Next.js-Durchgang tat das nicht. Das ist eine behebbare Team-Gewohnheit, keine Framework-Eigenschaft — wir haben es in der Tabelle gelassen als Erinnerung, dass der größte Teil des CLS selbstverschuldet ist.

Developer Experience: Wie sich die Builds tatsächlich angefühlt haben

Wir haben auch 200 Entwickler befragt, die beide Frameworks in Produktionskontexten ausgeliefert haben. Die selbsteingeschätzten Mediane dieser Gruppe stimmten eng mit unserer eigenen Erfahrung überein:

• Setup bis zur ersten deployed Page: 15 Minuten Median mit TanStack Starts CLI-Scaffolding (das ist das, was TanStack Ship vorkonfiguriert ausliefert) gegenüber 28 Minuten Median für äquivalente Next.js + Vite-alternative Toolchains — größtenteils wegen der Konfiguration des Deployment-Ziels statt dem Schreiben von Pages.
• Router Guards und Preloading. TanStack Routers beforeLoad-Guards, typisierte Suchparameter und Prefetch-on-Intent waren das am häufigsten gelobte DX-Feature in unserer Umfrage. Next.js Middleware deckt ähnliches Terrain ab, aber mit String-Matching Path-Konfiguration und weniger Typ-Flow zwischen Routendefinition und Navigationsaufrufen.
• Migrationsaufwand. Entwickler, die vom Next.js Pages Router kamen, berichteten von 2–3 Wochen, um mit dem Server-Component-Mentalmodell des App Routers vertraut zu werden. Entwickler, die von React SPA + Remix-Style-Loadern kamen, berichteten von 4–6 Tagen, um mit TanStack Router vertraut zu werden. Ihre Ergebnisse variieren je nach dem Modell, das Sie bereits kennen — aber das Loader-Modell hat für die meisten SPA-Ära-Teams weniger Regeln zum Verlernen.

Deployment-Modelle: Edge, Serverless und Lock-In

Alle Deployment-Ziele funktionieren mit beiden Frameworks, mit unterschiedlicher Reibung:

• Cloudflare Workers. Die besten TTFB- und Cold-Start-Zahlen aller Ziele, die wir gemessen haben, und nativer D1-Zugriff von Server Functions in TanStack Start. Next.js auf Workers (@opennextjs/*-Adapter) funktioniert, fügt aber eine Adapter-Schicht hinzu, die Sie besitzen.
• Vercel. Der Weg des geringsten Widerstands für Next.js — null Konfiguration, Preview Deployments und die Edge Runtime schließt den größten Teil der Performance-Lücke. Der Kompromiss ist Plattform-Kopplung: Die Teile Ihrer App, die auf next/*-Runtime-Helper setzen, porten nicht sauber.
• Selbstgehostetes Node (Railway, Render, Fly.io). Für beide in Ordnung, und der Ausstieg, der Vercel ehrlich hält. Next.js' Build-Caching verhielt sich in unseren Läufen weniger transparent über Rekomplilierungszyklen; TanStack Starts Build ist eine Standard-Vite-Pipeline, die Sie inspizieren können.

Wann Next.js trotzdem gewinnt

Das ist der Abschnitt, den Vendor-Vergleiche auslassen, und der Grund, warum wir beide Builds ausgeliefert haben: Es gibt echte Situationen, in denen die Wahl von TanStack Start im Jahr 2026 der falsche Anruf wäre.

1. Ihr Team denkt bereits in Server Components. Wenn Ihre Ingenieure im App-Router-Modell heute produktiv sind, kauft ein Rewrite Ihnen 30–50% bessere interaktive Metriken und kostet Sie Monate an Velocity. Dieser Kompromiss rentiert sich selten.
2. Sie brauchen das Next.js-first-Tooling des React-Ökosystems. Einige Auth-, Commerce- und CMS-Integrationen liefern Next.js-first Beispiele und Adapter. Sie können sie anpassen, aber Sie passen an, statt zu installieren.
3. Hiring und Einarbeitung. Next.js taucht in deutlich mehr Stellenbeschreibungen auf. Wenn Sie 10-köpfige Teams pro Jahr besetzen, ist die Größe des vertrauten Rekrutierungspools ein legitimer architektonischer Input.
4. Tiefe Abhängigkeit von Vercel-Produkten. Wenn Sie Vercels Analytics, KV, Cron und Preview-Pipelines als Produkte nutzen, ist das Bleiben bei Next.js kohärent. Das Porten dieser Integrationen ist echte Arbeit.

Entscheidungsmatrix: Welches Framework für welches Team

FAQ

Ist TanStack Start 2026 produktionsreif? Ja für die SaaS-Style-Workloads, die wir ausliefern — SSR, Streaming, Auth und Billing laufen damit in Produktion (TanStack Ship ist darauf gebaut). Es ist jünger als Next.js, also erwarten Sie weniger Stack-Overflow-Antworten und schnellere Breaking Changes auf dem Weg zur 1.0-Ära-Stabilität.

Ersetzt TanStack Start React Server Components? Nein. Es nimmt eine andere Position ein: Server Functions plus eine clientseitige App, die Server-rendert, statt RSC als Kompositionseinheit. Sie verlieren RSC's Zero-JS-Leaf-Components; Sie gewinnen ein einzelnes, serialisierbares Datenlade-Modell.

Wie groß war der Bundle-Unterschied in Ihren Builds? Unsere Dashboard-Route lief mit ~38% weniger Client-JavaScript auf TanStack Start, hauptsächlich getrieben durch die Abwesenheit des Server-Component-Client-Runtimes und kleineren Router-Code. Bei reinen Marketing-Pages verengte sich die Lücke auf einstellige Werte.

Was ist mit SEO — ranken beide Frameworks gleich? In unseren Builds lieferten beide crawlbaren HTML-Code mit korrekten Meta und Sitemaps, und wir sahen keinen Indexierungsunterschied. Wenn SEO auf einem JavaScript-Framework Ihr Anliegen ist, haben wir unser Production-Setup separat dokumentiert in TanStack vs Next.js for SEO.

Fazit

Die ehrliche Zusammenfassung, dasselbe SaaS auf beiden zu bauen: TanStack Start + Cloudflare Workers ist messbar schneller bei den Metriken, die Nutzer spüren — TTFB, First Interactive, CLS — und sein Router entfernt eine Klasse von Datenabruf-Bugs. Next.js bleibt die sicherere organisatorische Wahl, wenn Teamvertrautheit, Ökosystem-Tiefe oder Vercel-Produkte Ihre Einschränkungen dominieren.

Wenn die erste Spalte Sie beschreibt, gibt Ihnen TanStack Ship den TanStack-Start- + Workers- + D1-Stack vorkonfiguriert — Auth, Billing und die Dashboard-Muster aus diesem Beitrag, die out of the box funktionieren, deploybar in unter 5 Minuten.

Wenn Sie das Framework als Teil einer breiteren Stack-Entscheidung abwägen, deckt unser Feldleitfaden Vite vs TanStack Start: Brauchen Sie actually ein Framework? ab, wann ein Plain-Vite-SPA ausreicht, und Warum wir von Next.js zu TanStack Start gewechselt haben dokumentiert die Migrationsmechanik von Ende zu Ende.