Vercel oder Netlify: Kalte Starts machen den Tarifvergleich unvollständig

Für eine vollständig statische Marketingseite hängt die Wahl zwischen Vercel und Netlify vor allem von Veröffentlichungen, Datenverkehr und Teamkosten ab. Bei einer dynamischen Next.js-Anwendung oder einem API-lastigen Dienst reicht der Tarifvergleich nicht: Kalte Function-Starts können die erste Antwort verzögern, und technische Limits können einen Endpunkt unabhängig vom Monatspreis einschränken.

Eine Plattform ist deshalb nicht für alle drei Projekte die günstigere oder schnellere Wahl. Entscheidend ist, welche Seiten vorgerendert werden, welche Routen bei einem Aufruf Rechenleistung benötigen und wie häufig diese Routen nach einer Ruhephase angefragt werden. Der veröffentlichte Latenzvergleich liefert dafür einen Anhaltspunkt, aber keine Prognose für jeden Tarif oder Standort.

Was in den Tarifen tatsächlich verbraucht wird

Die Netlify-Preisseite nennt für Pro 20 US-Dollar im Monat mit anfänglich 3.000 Credits und unbegrenzten Teammitgliedern; eine Produktionsveröffentlichung verbraucht 15 Credits, Bandbreite 20 Credits pro Gigabyte und Compute 10 Credits pro Gigabyte-Stunde. Auch Webanfragen greifen auf das gemeinsame Kontingent zu. Vorschau- und Branch-Deployments werden dagegen nicht wie Produktionsveröffentlichungen berechnet. Ein Team kann daher häufig Änderungen begutachten, während vor allem das Veröffentlichen auf der Hauptdomain Credits kostet.

Die Vercel-Preisseite führt Pro ab 20 US-Dollar monatlich mit 20 US-Dollar Nutzungsguthaben, Entwicklerplätze für 20 US-Dollar pro Monat und eine Funktion zur Kaltstartvermeidung auf. Kostenlose Betrachterplätze sind eine andere Rolle als Entwicklerplätze. Der Hobby-Tarif ist für private, nichtkommerzielle Nutzung vorgesehen und damit kein gleichwertiger Maßstab für eine geschäftliche Website. Wer lediglich die beiden Pro-Einstiegspreise nebeneinanderstellt, übersieht sowohl die Sitzkosten als auch den unterschiedlichen Zuschnitt der Verbrauchsabrechnung.

Ein ausdrücklich hypothetisches Netlify-Beispiel macht die gemeinsame Kreditgrenze greifbar: Zwanzig Produktionsveröffentlichungen und 50 Gigabyte ausgelieferte Daten würden zusammen 1.300 Credits verbrauchen, noch bevor Compute und Webanfragen hinzukommen. Bei einer selten aktualisierten Seite kann dagegen der Datenverkehr den größeren Anteil ausmachen. Auf Vercel muss dieselbe Arbeitslast nach den dortigen Nutzungspositionen und der Zahl der benötigten Entwicklerplätze bewertet werden; Credits und Dollar-Guthaben sind keine direkt vergleichbaren Einheiten.

Was kalte und warme Antworten im Versuch trennt

Der im Januar 2026 veröffentlichte 48-Stunden-Test mit 3.044 Anfragen an dieselbe dynamische Next.js-Anwendung erfasste bei kalten Starts Antworten von mehr als drei Sekunden auf Netlify und ungefähr einer Sekunde auf Vercel. Das sind Ergebnisse der untersuchten Deployments, keine allgemeingültigen Plattformzeiten. Im Versuch waren Netlify-Antworten auch bei bereits warmen Laufzeitumgebungen vergleichsweise langsam; Vercel lieferte Seiten schneller aus, während seine API-Routen häufiger kalt starteten und sich bei der Antwortzeit anders verhielten als die Seiten.

Für die Messung waren alle Seiten ausdrücklich dynamisch. Die API-Routen simulierten leichte Verarbeitung ohne externe Datenbankabfrage; ein realer Dienst mit Datenbank, Authentifizierung oder größeren Nutzdaten kann sich daher anders verhalten. Als kalt galt der erste Aufruf einer gestarteten Laufzeitumgebung. Die Anfragen kamen nach langen Pausen aus Ashburn und Hillsboro in den USA und liefen auf kostenlosen Tarifen mit Standardeinstellungen. Der Aufbau macht seltene Zugriffe sichtbar, bildet aber weder starken gleichzeitigen Traffic noch Besucher in Deutschland, Österreich oder der Schweiz unmittelbar ab.

Auch die Messgrößen unterscheiden sich nach Routentyp: Für Seiten wurde der Zeitpunkt erfasst, an dem das Dokument interaktiv war, für API-Antworten die Zeit bis zum ersten Antwortbyte. Diese Werte sollte man nicht zu einem einzigen Seiten-und-API-Durchschnitt vermischen. Für die Hostingwahl ist die Trennung aufschlussreicher: Eine schnelle dynamische Seite sagt wenig über einen selten aufgerufenen API-Endpunkt aus, und ein hoher Kaltstartwert allein erklärt nicht die Geschwindigkeit warmer Antworten.

Statische Marketingseite: Veröffentlichungen vor Laufzeit

Bei einer Marketingseite, die als fertige Dateien ausgeliefert wird, löst der normale Seitenaufruf keine serverseitige Rendering-Function aus. Der gemessene Kaltstart dynamischer Next.js-Routen ist für diesen Fall deshalb kein tragfähiges Auswahlkriterium. Mehr Gewicht haben das Volumen ausgelieferter Bilder und anderer Dateien, die Häufigkeit von Produktionsveröffentlichungen sowie die Frage, wer Änderungen vorbereiten, prüfen und freigeben muss.

Netlifys gemeinsames Creditkonto passt zu einem Team, das Veröffentlichungen und Datenverkehr ungefähr planen kann und viele Mitglieder am Projekt beteiligt. Bei häufigen Produktionsveröffentlichungen wirkt sich die wiederkehrende Credit-Belastung stärker aus; Vercels Modell mit unbegrenzten Deployments kann dann günstiger passen, sofern Entwicklerplätze und übrige Nutzung in der Rechnung berücksichtigt sind. Beide Dienste bieten Vorschauabläufe. Eine reine Featureliste zeigt hier weniger als die Unterscheidung zwischen Vorschau und tatsächlicher Veröffentlichung.

Next.js-Anwendung: Unterstützung beantwortet die Latenzfrage nicht

Die Netlify-Dokumentation zu Next.js beschreibt Unterstützung für SSR und ISR: Der OpenNext-Adapter stellt dafür sowie für API-Routen serverlose Functions bereit und führt Middleware am Edge aus. Vorgerenderte Seiten liegen im Route Cache; nach einem Deployment wird ihr erster Zugriff über eine Function bedient. Eine Next.js-Seite kann damit technisch vorgerendert sein und dennoch einen anderen Auslieferungsweg haben als eine einfache Sammlung statischer Dateien.

Für eine Anwendung mit selten besuchten dynamischen Seiten zählt besonders die Verzögerung beim ersten Aufruf. Bei häufig aufgerufenen oder wirksam zwischengespeicherten Routen fällt derselbe Start seltener ins Gewicht. Die Verteilung zwischen vorgerenderten, zwischengespeicherten und bei jeder Anfrage berechneten Seiten ist deshalb aussagekräftiger als das Etikett „Next.js-Unterstützung“. Hinzu kommt der Bereitstellungsablauf: Eine neue Version kann Caches und laufende Instanzen verändern, sodass die Zugriffe unmittelbar nach einer Veröffentlichung gesondert relevant sind.

Vercels Pro-Angebot enthält eine Maßnahme zur Kaltstartvermeidung, die im Versuch auf kostenlosen Tarifen nicht als Pro-Konfiguration untersucht wurde. Die gemessenen Sekundenwerte lassen sich daher nicht auf einen bezahlten Produktionsbetrieb übertragen. Für ein Team mit kritischen dynamischen Seiten spricht der Versuch dafür, kalte und warme Aufrufe dieser Seiten getrennt zu beurteilen; aus der bloßen Unterstützung desselben Frameworks folgt noch keine gleiche Antwortzeit.

API-lastiger Dienst: Grenzen und Routenantworten entscheiden

Bei einem API-lastigen Dienst rücken neben der Latenz die Größe der Nutzdaten, die Laufzeit und der Speicherbedarf in den Vordergrund. Die Vercel-Dokumentation zu Functions begrenzt Anfrage- und Antwortkörper jeweils auf 4,5 MB; mit Fluid Compute gelten 2 GB Standardspeicher, bis zu 4 GB im Pro-Tarif, 300 Sekunden Standardlaufzeit, 800 Sekunden als reguläre Pro-Obergrenze und eine erweiterte Grenze von 1.800 Sekunden nur als Beta. Ein Endpunkt für große direkte Dateiübertragungen kann somit bereits an der Payload-Grenze scheitern. Längere zulässige Laufzeiten ändern an dieser Grenze nichts.

Für kleine, häufige API-Antworten liegt der Engpass anders: Relevant sind die Zahl der Function-Aufrufe, Rechenzeit und Speicher sowie die Häufigkeit kalter Instanzen. Netlifys Compute und Webanfragen verbrauchen dabei gemeinsame Credits; Vercel rechnet Function-Nutzung über eigene Verbrauchsgrößen ab. Bei selten aufgerufenen Endpunkten wie einem internen Berichtsexport verdient die erste Antwort besondere Aufmerksamkeit. Bei einem stark genutzten API-Dienst zählen zusätzlich die warmen Antwortzeiten und die tatsächliche Lastverteilung. Gerade weil Seiten- und API-Routen im veröffentlichten Versuch unterschiedlich abschnitten, taugt der schnelle Seitenaufruf nicht als Ersatzwert für den API-Betrieb.

Lesen Sie auch:

• Eine EU-Cloud ist nicht automatisch souverän – 48 Kriterien machen den Unterschied
• Gumroad oder Payhip: Bei 100 Euro kostet der Unterschied mehr als fünf Euro
• Zendesk oder Freshdesk: KI-Sitzungen machen den Einstiegspreis trügerisch