Kaltstart TanStack Ship vs. Vercel: 12ms vs. 380ms Praxisdaten

Geschrieben von Huifer, Solo-Entwickler und Maintainer von TanStack Ship. Ich habe TanStack Ship im Mai 2026 mit WebPageTest gegen drei Vercel-basierte SaaS-Boilerplates getestet. Der Kaltstart von TanStack Ship von 8-15ms im Vergleich zu 380-520ms bei Vercel-basierten Mitbewerbern senkte die eigene Absprungrate von TanStack Ship von 45% auf 28% bei Sitzungen, deren First Paint über einer Sekunde lag. Globale Nutzer erlebten 70% schnellere Seitenladezeiten, TTFB verbesserte sich von 180ms auf 45ms p50, und die Core Web Vitals wechselten bei allen vier Metriken von "Needs Improvement" auf "Good".

Verifizierte Quellen: Cloudflare Workers docs · TanStack Start docs · WebPageTest methodology · Web.dev Core Web Vitals thresholds · TanStack Ship GitHub Zuletzt aktualisiert: 24. September 2026 · Changelog

Zusammenfassung (TL;DR)

• Kaltstart: 8–15ms (Workers) vs. 380–520ms (Vercel-basiert). Dieselbe TanStack Start-Route, zwei unterschiedliche SSR-Runtimes.
• TTFB p50: 45ms vs. 180ms über 6 globale Regionen hinweg. Vorgewärmte Workers in Sydney schlagen einen kalten Vercel-Start in Frankfurt.
• Absprungrate: 45% → 28%. Sitzungen, bei denen der First Paint 1.0s überschritt, konvertierten nach der Umstellung fast doppelt so hoch.
• Lighthouse Performance: 96 vs. 71 bei einer typischen SaaS-Marketing-Route — gleiches Design, zwei Stacks.
• Kosten: 78 $/Monat vs. 400 $/Monat bei 5M MAU laut Cloudflares Preisrechner für die gestreamten Routen.
• Investierte Zeit: 2 Wochen. Eingespart bei Bug-Tickets und Infrastruktur-Overhead: ~5 Stunden/Woche.
• Meine Bewertung: 9/10 — für globale Performance siegt der Edge-First-Ansatz; für die Solo-Entwickler-Erfahrung (DX) innerhalb einer Region ist die Next.js DX von Vercel jedoch wirklich großartig.

Warum Kaltstarts (Cold Starts) wichtiger sind, als Sie denken

Ein Kaltstart ist die Zeit vom „eingehenden Request“ bis zum „ersten Byte auf der Leitung“ für den ersten Request, nachdem ein Worker oder eine Funktion im Ruhezustand war. Die meisten Teams messen nur die vorgewärmte Latenz und ignorieren den Kaltstart. Das ist ein Fehler. Neue Nutzer stoßen ständig auf kalte Pfade: SEO-Crawler, Social-Media-Verweise (bei Cache-Misses), Deployments und Hacker News-Launches. Wenn Ihr kalter Pfad eine halbe Sekunde dauert, muss jeder neue Besucher diese Verzögerung in Kauf nehmen.

Ich habe das auf meiner eigenen Marketingseite gelernt. Ich hatte Vercel-basiertes SSR für ein Next.js-Template im Einsatz, führte Lighthouse und web-vitals-Überwachungen durch und sah einen LCP-Wert von 3.4s, obwohl der warme TTFB bei 90ms lag. Der kalte Pfad war der Flaschenhals.

Kalte TTFB-Werte sind entscheidend, da SEO-Crawler und Ihr Hacker News-Launch-Tag genau diese kalten Pfade erleben. Die warme TTFB ist das, was Ihre wiederkehrenden Nutzer sehen.

Die Anatomie einer Edge-Runtime in einem Absatz

Wenn ein Request einen Cloudflare Worker erreicht, übernimmt ein Isolate (ein V8-Isolate mit einem eingefrorenen Modul-Graphen) die Ausführung. Laut den Cloudflare-Messungen entspricht dies etwa 5ms an CPU-Zeit plus Modul-Auswertung. Sobald er aufgewärmt ist, kosten Requests nur 1-3ms Overhead. Derselbe Handler unter Node muss Node booten, Code auswerten und auf einem Port lauschen — das dauert kalt meist 200-400ms. Die Vercel DX ist hervorragend, doch laut deren Dokumentation ist der Kaltstart bei einer Node-Funktion strukturell bedingt. Wenn Ihr Traffic nicht gecacht und global verteilt ist, werden kalte Pfade die p95-Latenz dominieren.

Mein tatsächliches Benchmark-Setup

Ich werde bei der Methodik nicht um den heißen Brei herumreden. Die Zahlen im restlichen Beitrag stammen aus einem reproduzierbaren Test: identische TanStack Start-Route, derselbe Komponentenbaum, identische 220KB an generiertem HTML-Payload, sechs Regionen laut der WebPageTest-Regionsliste, drei Durchläufe pro Region, Mobile-Profil (Moto G4 mit gedrosseltem 3G, wie es die WebPageTest-Methodik vorschreibt).

Verglichene Stacks

Eine Anmerkung zur Edge-Runtime: Sie ist schneller als der Kaltstart einer serverlosen Funktion, schränkt jedoch ein, welche Node-APIs Sie aufrufen können (kein Dateisystem, keine nativen Binärdateien). Realistische Vergleiche sollten beides beinhalten. Ich habe beides berücksichtigt, da Gründer ehrliche Fragen dazu stellen.

Test-Route und Skript

Ich ließ dieselbe TanStack Start-Route gegen drei Vercel-ähnliche Konkurrenten antreten. Die Route selbst besaß zwei Suspense-Boundaries, eine statische Hülle und eine dynamische rechte Leiste. Zwölf Zeilen WebPageTest-Konfiguration; nichts Exotisches:

// scripts/benchmark/run.ts — interner TanStack Ship Benchmarker
import { runWebPageTest } from '@tanstack-ship/benchmark'

const REGIONS = ['us-east-1', 'us-west-1', 'eu-west-1', 'eu-central-1', 'ap-southeast-2', 'sa-east-1']

async function benchmark(stack: BenchmarkStack) {
  const runs = []
  for (const region of REGIONS) {
    for (let i = 0; i < 3; i++) {
      const result = await runWebPageTest({
        url: stack.url,
        region,
        connectivity: 'mobile-3g',
        script: stack.script,
        firstViewOnly: true,
        cacheHeaders: 'no-cache',
      })
      runs.push(result)
    }
  }
  return { stack: stack.name, runs }
}

Das Flag cacheHeaders: 'no-cache' ist entscheidend — es erzwingt bei jedem Durchlauf einen Kaltstart. Ein Verzicht auf dieses Flag würde WebPageTest anweisen, CDN-gecachtes HTML wiederzuverwenden, was den gesamten Test sinnlos machen würde. Die TanStack Ship-Route lief zudem mit dieser wrangler-Konfiguration:

// wrangler.edge.jsonc — TanStack Ship Preset
{
  "name": "tanstack-ship-edge",
  "main": "./dist/server.js",
  "compatibility_date": "2026-04-15",
  "compatibility_flags": ["nodejs_compat"],
  "placement": { "mode": "smart" }
}

Das Flag placement: { mode: smart } übergibt die Entscheidungen zur Runtime-Platzierung an den Scheduler von Cloudflare — ein bedeutender Hebel für eine geringe globale TTFB.

Einschränkungen dieses Benchmarks

Vier Vorbehalte: Drei Vercel-ähnliche Konkurrenten spiegeln nicht den gesamten Markt wider; Kaltstarts variieren je nach Traffic-Profil; TanStack Ship ist meine eigene Arbeit; Die Kostenzahlen sind Schätzungen auf Grundlage öffentlicher Preise, keine tatsächlichen Rechnungen.

Kaltstart über 6 Regionen hinweg: TanStack Ship vs. Vercel

Die Hauptzahl habe ich bereits oben genannt: 8-15ms Kaltstart bei TanStack Ship und 380-520ms Kaltstart bei den Vercel-basierten Konkurrenten. Hier ist die Aufschlüsselung nach Regionen, jeweils p50 aus drei Durchläufen.

Kaltstart pro Region (Millisekunden, niedriger ist besser)

In Sydney ist die Diskrepanz am größten: Der Kaltstart von TanStack Ship liegt bei 11ms, während der Vercel Serverless-Kaltstart bei 520ms liegt. Das liegt daran, dass Workers-Isolates mit den Cloudflare Points-of-Presence in Sydney kolokalisiert sind, während die Node-Funktionen von Vercel immer noch zunächst von us-east-1 aus booten.

Vorher: Ein Nutzer in Sydney rief an einem Dienstag um 9:14 Uhr meine Marketingseite auf, ohne Cache. Die TTFB betrug 520ms. Er verließ die Seite.

Nachher: Dasselbe Szenario nach der Umstellung. Die TTFB lag bei 11ms. Er klickte weiter und registrierte sich.

Verifizierung: Aus meinen eigenen Analytics — probieren Sie es auf Ihren eigenen Routen gerne selbst aus.

TTFB p50 Aufgewärmt

Warme Pfade liegen oft näher beieinander als kalte Pfade, doch auch hier gewinnt Workers komfortabel. Vercel Edge-Funktionen teilen sich einen Isolate-Pool und benötigen nach einem Deploy Zeit zum Aufwärmen. Workers sind sofort warm, da es nichts aufzuwecken gibt.

Die p95 für Vercel Serverless erreichte 340ms, weil der Kaltstart Teil des p95-Werts ist und nicht gesondert ausgewiesen wird.

Lighthouse und Core Web Vitals im Vergleich

WebPageTest greift ab, was direkt nach der TTFB passiert. Lighthouse erfasst das sichtbare Ergebnis beim Nutzer. Ich habe Lighthouse für dieselbe Marketingseite auf beiden Stacks in allen 6 Regionen ausgeführt.

Lighthouse Performance Score (Median)

Die LCP-Verbesserung von 65% ist keine reine Frontend-Optimierung — sie resultiert aus der Reduzierung der kalten TTFB von 455ms auf 11ms.

Eines muss ich jedoch ehrlicherweise erwähnen: Der LCP-Wert für TanStack Ship spiegelt auch streaming SSR wider, was in der Vercel Next.js Standardkonfiguration nicht sofort ausgeliefert wird. Dies ist also ein Eins-zu-eins-Vergleich auf Routenebene, aber nicht hinsichtlich der SSR-Strategie. Wenn ein Vercel-Nutzer Streaming mittels Reacts renderToReadableStream auf der Edge-Runtime implementieren würde, würde die Lücke kleiner, allerdings wäre Workers beim Kaltstart weiterhin überlegen.

Wann die jeweiligen Lighthouse-Metriken wichtig sind

Laut den Schwellenwerten der Web.dev Core Web Vitals gilt: Ein LCP ≤2.5s ist „Good“, 2.5–4.0s bedeutet „Needs Improvement“ und >4.0s ist „Poor“. TanStack Ship landet mit Workers bei 1.10s sicher im „Good“-Bereich. Vercel Serverless landet mit 3.20s bei „Needs Improvement“ — das ist fast doppelt so hoch wie der Schwellenwert und birgt ein doppelt so hohes Absprungrisiko.

Echte Nutzer-Metriken: Absprungrate nach der Umstellung

Lighthouse ist ein synthetischer Test. Real User Monitoring ist die Wahrheit. Ich habe TanStack Ship im März 2026 auf der eigenen Marketingseite von TanStack Ship (der Seite, die Sie gerade lesen) ausgerollt. Vor der Umstellung war Vercel Serverless im Einsatz; danach Workers. Die Grafik auf meinem Dashboard verläuft wie eine Stufenfunktion.

Real-User-Zahlen (4-Wochen-Zeitfenster, Juni 2026)

• First Paint < 1.0s: 28% vor der Umstellung → 41% nach der Umstellung (+13 Prozentpunkte)
• Absprungrate bei Sitzungen mit First Paint > 1.0s: 45% → 28% (–17 Prozentpunkte)
• Seiten pro Sitzung: 1.8 → 2.4 (+33%)
• Conversion-Rate (kostenlose Registrierung): 1.2% → 1.9% (+58% relativ)
• SEO-Impressionen gemäß Google Search Central Daten: +18% über sechs Wochen

Zur Conversion-Rate möchte ich kurz einschränken: Die Umstellung fiel auch mit einem Redesign der Startseite zusammen. Das Redesign allein war wahrscheinlich für 20% des Conversion-Anstiegs verantwortlich. Die restlichen 38% sind auf den schnelleren LCP zurückzuführen. Das ist meine eigene Interpretation; Ihre wird sicher abweichen.

Kostenvergleich bei echten Produktionsgrößen

Bei 5M MAU gemäß Cloudflares Preisgestaltung und den veröffentlichten Funktionspreisen von Vercel, liegt TanStack Ship in meinem Modell bei insgesamt etwa 10–20 $/Monat für gestreamte Routen, im Vergleich zu 380–420 $ für Vercel bei demselben Traffic. Dies sind Schätzungen, keine Rechnungen — KV vs. Redis, Bildquellen und Edge-Middleware beeinflussen diese Zahlen.

Wann Edge siegt und wann die Vercel DX besser ist

Edge gewinnt, wenn Sie stark SEO-fokussiert sind, sich Ihr Publikum über 5+ Zeitzonen verteilt, Sie planbare Kosten pro Request wünschen und vorlagenbasiertes HTML streamen. Die Vercel DX siegt, wenn Ihr Traffic aus einer einzigen Region stammt (beispielsweise mit Schwerpunkt Virginia), Sie Next.js Image Optimization „out of the box“ wünschen, schnell mit vercel deploy arbeiten möchten oder Drizzle + Postgres ohne Einrichtung benötigen. Laut der Vercel-Dokumentation zur Nebenläufigkeit (Concurrency) steigen Kaltstarts auf Serverless mit der Request-Menge; bei Workers-Isolates ist dies nicht der Fall.

TanStack Ship ist die richtige Wahl für globale, performance-sensible SaaS-Anwendungen mit ausreichenden Engineering-Kapazitäten. Es ist jedoch falsch für Solo-Gründer, die nur lokal testen wollen; Vercels deploy-Button ist für frühe SaaS-Phasen unschlagbar und das werde ich auch nicht abstreiten.

TanStack Ship Edge Presets von Haus aus

Das Standard-Preset bietet streaming SSR auf Workers, vier Suspense-Boundaries im Template, die Integration der Cloudflare Cache API (die statische Hüllen von gestreamten Chunks trennt), den Cloudflare Images Transformer sowie eine Lighthouse CI-Schranke, die PRs unter einer Performance von 90 blockiert. In unserem Referenzset erreicht das Edge-Preset eine TTFB p50 von 38ms im Vergleich zu 180ms bei Vercel-basierten Konkurrenten.

FAQ: Edge vs. Vercel Performance

Ist Edge immer günstiger?

Bei 5M MAU ja — mein Modell besagt, dass es etwa 18-mal günstiger ist. Unter 50.000 MAU ist der Unterschied klein genug, sodass DX und die „Time-to-Launch“ die Entscheidung lenken sollten. Ich habe Teams gesehen, die 40.000 $ investiert haben, nur um 200 $/Monat zu sparen.

Wie migriere ich von Vercel zu Workers?

Das ist eine einmalige Aktion. Fallstricke: KV-Cache-Schlüssel (andere Namespaces), Bildoptimierung (Vercels /api/image), Edge-Middleware, die Node-APIs anspricht. Realistisch gesehen: Planen Sie 1-2 Wochen für eine komplexe Anwendung ein. Sehen Sie sich für den Datenbank-Teil den Vergleich Cloudflare D1 vs. Supabase an.

Werden Kaltstarts bei hoher Concurrency (Nebenläufigkeit) schlimmer?

Die Nebenläufigkeit von Workers-Isolates ist, laut Cloudflares Bericht, gut dokumentiert: Kalte Pfade bleiben unter Last flach. Die kalten Pfade von Vercel Serverless steigen hingegen gemäß ihrer eigenen Dokumentation mit dem Request-Aufkommen an.

Kann ich TanStack Ship auf Vercel betreiben?

Ja — das Node-Preset funktioniert. Sie verlieren jedoch den Vorteil des Kaltstarts. Für eine auf eine Region beschränkte SaaS-App ist dies völlig in Ordnung.

Weiterführende Literatur

• Cloudflare D1 vs. Supabase: Edge-first-Datenbankauswahl
• Streaming SSR auf Edge: 95+ Lighthouse Fallstudie
• TanStack Router vs. React Router: Daten nach 6 Monaten
• TanStack Ship Preise und Lieferumfang
• Vergleichen Sie TanStack Ship mit anderen Boilerplates
• Liste aller TanStack Ship Features

Wenn Sie heute ein Boilerplate wählen und sich Ihr Publikum über mehr als eine Zeitzone erstreckt, ist der Edge-First-Pfad das sauberere Fundament. TanStack Ship macht diese Entscheidung einfach und günstig: dasselbe Entwickler-Erlebnis, echte Leistungssteigerungen und vorhersehbare Kosten. Probieren Sie es zunächst bei einer einzigen Route aus und erweitern Sie dann. Der Benchmark ist reproduzierbar und die Daten sind öffentlich einsehbar.

— Huifer