Ein Kunde rief mich an einem Montagmorgen vor einem Jahr an. Keine Nachricht. Ein Telefonanruf. Das ist nie ein gutes Zeichen. Er hatte eine Next.js-Marketingwebseite auf Vercels Pro-Plan am Donnerstag vorher deployt, eine Produkteinführung übers Wochenende durchgeführt und wachte zu einer 340-Dollar-Rechnung in seinem Postfach auf. Die Website lief großartig. Der Traffic ist in die Höhe geschossen. Und Vercel hatte jedes Gigabyte Daten, das ihre Server verließ, stillschweigend abgerechnet. Er hatte keine Ausgaberobergrenze gesetzt. Keine Benachrichtigung konfiguriert. Nichts.
Dieser Anruf ist der Grund, warum ich jetzt vor jedem Production-Deployment mit jedem Kunden zwanzig Minuten Vercel-Abrechnungshygiene durchgehe.
Hier ist, was du über Vercels Bandbreitenabrechnung wissen musst, warum es Leute überrumpelt und was du wirklich dagegen tun kannst.
---
Was „Egress" bei Vercel wirklich bedeutet
Egress ist Daten, die aus Vercels Netzwerk zum Endnutzer übertragen werden. Jedes Bild, jedes JavaScript-Bundle, jede API-Response, jede Font-Datei. Wenn es ihre Edge verlässt und einen Browser erreicht, zählt es.
Im Hobby-Plan bekommst du 100GB Bandbreite pro Monat, inklusive. Bei Pro sind es 1TB. Klingt nach viel. Aber hier ist der Haken: Wenn du große Bilder auslieferst, Server-Side Rendering auf Seiten mit großen JSON-Payloads machst, oder deine App einen plötzlichen Traffic-Spike bekommt, kannst du 1TB schneller überschreiten, als du denkst. Vercel berechnet $0,15 pro GB Überschuss bei Pro, Stand jetzt (immer ihre aktuelle Pricing-Seite checken, weil das sich ändert).
Also 500GB über deinem Limit sind $75. Nicht katastrophal. Aber ein viraler Moment, ein verpfuschtes Image-Optimierungssetup oder ein Scraper, der deine API-Routes hammert? Das können tausende sein.
Warum das die Leute überrascht
Das Ding ist, lokale Entwicklung gibt dir null Hinweise. Du buildest schnell, deployest schnell, alles fühlt sich gut an. Vercels Dashboard zeigt Bandbreitennutzung, aber es schreit dich nicht an. Wenn du nicht proaktiv einen Billing-Alert eingerichtet hast, erfährst du davon, wenn die Rechnung ankommt.
---
Die Configs, die deine Rechnung am ehesten ruinieren
Ich habe viele Deployments bei Seahawk auditiert. Es gibt vier Übeltäter, die ich immer wieder sehe.
1. Unoptimierte Bilder, die next/image umgehen
next/image ist wirklich gut in dem, was es tut. Es ändert Größe, konvertiert zu WebP und cached. Aber ich habe Projekte gesehen, wo Entwickler Bilder direkt aus einem <img>-Tag zogen, der auf Bilder in voller Auflösung in einem S3-Bucket zeigte, proxiert durch eine Vercel API-Route. Jeder Request zog eine 4MB-JPEG durch Vercels Netzwerk statt einer 200KB-WebP von einer CDN-Edge. Multiplizier das mit 50.000 Page Views und rechne selbst.
Verwende next/image immer mit einer korrekten remotePatterns-Konfiguration. Wenn die Bildquelle extern ist, stelle sicher, dass sie den CDN-Cache nutzt und nicht über deine serverlosen Funktionen läuft.
2. API-Routen, die große Datenmengen zurückgeben
2021 baute ich einen E-Commerce-Produktkatalog für einen britischen Einzelhändler. Ihre API-Route holte eine Produktliste aus ihrer Datenbank und gab das gesamte Produktobjekt zurück, inklusive Feldern, die das Frontend nie nutzte. Beschreibungen, interne SKU-Notizen, Variantendaten – alles. Jede Antwort war etwa 80 KB groß statt der benötigten 12 KB.
Kürze deine API-Antworten. Gib nur die Felder zurück, die der Client tatsächlich verbraucht. Wenn du etwas wie Prisma nutzt, verwende select, um zu begrenzen, was du abrufst. Wenn du eine API von Drittanbietern verwendest, transformiere und reduziere die Payload, bevor du sie weitergibst.
3. ISR mit kurzen Revalidierungsfenstern auf stark frequentierten Routen
Incremental Static Regeneration ist in der Theorie brilliant. In der Praxis: Wenn du revalidate: 30 auf einer Seite setzt, die 10.000 Treffer pro Minute bekommt, cachst du immer noch korrekt. Aber wenn du revalidate: 1 setzt, weil du Echtzeitaktualisierungen wolltest und vergessen hast, es zu ändern... machst du im Grunde SSR mit zusätzlichen Schritten und bezahlst für den Egress bei jedem Cache-Miss.
Sei gezielt bei deinen Revalidierungsfenstern. Die meisten Inhalte müssen nicht jede Sekunde revalidiert werden.
4. Serverlose Funktionen ohne Caching-Header
Dieser Punkt ist subtil. Wenn deine serverlose Funktion keine Cache-Control-Header enthält (oder Vercels s-maxage / stale-while-revalidate-Kombination), wird die Antwort nicht am Edge gecacht. Jede Anfrage trifft die Funktion und durchläuft die vollständige Reisenfolge. Du verlierst den CDN-Vorteil komplett und bezahlst Egress bei jeder einzelnen Antwort.
`` Cache-Control: s-maxage=3600, stale-while-revalidate=86400 ``
Allein dieser Header hat Kunden echtes Geld gespart. Ohne Spaß. Vercels eigene Caching-Dokumentation erklärt das Header-Verhalten ausführlich. Lies sie einmal richtig durch.
---
Billing Alerts einrichten (bevor du sie brauchst)
Das sollte Schritt eins sein, bevor ein Production Deploy. Nicht Schritt sieben.
- Gehe zu deinen Vercel Team Settings.
- Unter Billing findest du Spend Management.
- Setze ein Spend Limit (harte Obergrenze, bei der Vercel Anfragen nicht mehr bearbeitet) oder einen Notification Threshold (sanfte Benachrichtigung, eine E-Mail wenn du eine bestimmte Summe erreichst).
- Ich würde empfehlen, eine Benachrichtigung bei 50% dessen zu setzen, was du als schmerzhaft erachten würdest, und ein hartes Limit bei etwa 120% deiner erwarteten monatlichen Rechnung.
Das Hard Cap ist ein zweischneidiges Schwert. Wenn du es erreichst, geht deine Website down. Also überleg dir das gut. Für eine Marketing-Website? Okay, begrenzen sie hart. Für eine SaaS mit zahlenden Nutzern? Setze großzügige Benachrichtigungen und beobachte das Dashboard stattdessen.
---
Die schwere Last anderswo unterbringen
Vercel ist kein CDN für statische Assets. Ich meine, es hat ein CDN, aber du zahlst pro Gigabyte dafür. Bei großen Mengen statischer Assets solltest du sie woanders lagern, wo es günstiger ist.
Ich leite große Mediendateien seit etwa achtzehn Monaten über Cloudflare R2. R2 hat keine Egress-Gebühren. Du zahlst für Speicher und Operationen, nicht für die Daten, die hinausgehen. Für bildlastige Seiten ist das eine ernsthafte Ersparnis. Ein Client von mir betreibt eine Fotografie-Portfolio-Plattform und zahlte etwa 180 Dollar pro Monat für Vercel Egress. Wir haben alle hochauflösenden Bilder und Gallery-Assets zu R2 verschoben, die Thumbnails über next/image laufen lassen, und die Vercel-Rechnung ist auf unter 40 Dollar gefallen.
Alternativen, die es zu kennen lohnt:
- Cloudflare Pages für statische Deployments, wo du Vercels Edge-Features nicht brauchst. Großzügiger kostenloser Plan, keine Egress-Gebühren.
- AWS CloudFront vor S3, wenn du bereits im AWS-Ökosystem bist. Die Transferkosten sind bei größerem Volumen niedriger als Vercels Überschussgebühren.
- BunnyCDN ist günstig und schnell für reine Asset-Lieferung. Ich habe es bei einigen High-Traffic-Migrationen von WordPress zu Next.js eingesetzt, wo das Asset-Volumen groß war.
Der Punkt ist: Vercel ist der richtige Ort, um deine Next.js-Anwendungslogik auszuführen. Es ist nicht immer der richtige Ort, um deine Gigabytes an Mediendaten zu servieren.
---
Nutzung in Echtzeit überwachen
Überprüfe dein Dashboard nicht erst am Ende des Monats. So kam mein Kunde dazu, mich an einem Montag anzurufen.
Ein paar Dinge, die ich tatsächlich nutze:
- Vercel Analytics gibt dir seitenbezogene Daten und ist nützlich, um zu erkennen, welche Routes den meisten Traffic generieren (und damit den meisten Egress).
- Axiom integriert sich sauber mit Vercels Log Drains und lässt dich die Request-Größe über die Zeit abfragen. Ich habe damit Ende 2022 angefangen und es war bei größeren Projekten nützlich, um Traffic-Spitzen mit Egress-Sprüngen zu korrelieren.
- Richte einen einfachen Cron ein (Vercel hat jetzt natives Cron-Support), der ihre API aufruft und einen Slack-Channel anschreibt, wenn die Bandbreite einen Schwellwert überschreitet. Ich habe eine schlanke Version davon für die Infrastruktur von Seahawk gebaut. Dauert zwei Stunden, spart viel Angst.
Die Vercel REST API stellt Deployment- und Nutzungsdaten bereit. Es ist nicht die eleganteste API der Welt, aber sie tut, was du für einfache Alerting brauchst.
---
Die Architektur-Entscheidung, über die niemand spricht
Hier ist etwas, das ich nicht oft diskutiert sehe: manchmal ist Vercel nicht die richtige Default-Wahl.
Wenn dein Projekt eine statische Marketing-Site ohne echte dynamische Funktionalität ist, brauchst du Vercel nicht. Cloudflare Pages oder Netlify's kostenloses Tier werden den Job machen ohne Egress-Bedenken. Du "verschwendest" Vercel nicht, du hast einfach nicht das richtige Werkzeug für die Workload.
Umgekehrt: Wenn du eine richtige Next.js-App mit Edge Middleware, Server Components und API Routes baust, die echte Arbeit verrichten, dann lohnt sich die Zahlung für Vercel. Die Developer Experience ist wirklich ausgezeichnet und das Edge-Netzwerk ist schnell. Nur musst du es von Anfang an richtig architektieren.
Der Fehler, den ich früh in meiner Karriere gemacht habe (um 2016, bevor Vercel überhaupt existierte, damals als ich noch Deployment auf Heroku und Netlify herausfand), war, die Deployment-Plattform als kostenloses Anhängsel zu behandeln. Die Plattformwahl prägt dein Kostenprofil genauso wie deine Datenbankwahl. Nimm es ernst.
---
FAQ
Fallen auf dem Hobby-Plan Egress-Gebühren an, wenn ich über 100GB gehe?
Nein. Beim Hobby-Plan berechnet Vercel keine Überschreitungsgebühren; sie drosseln oder unterbrechen das Deployment, sobald du das Limit erreichst. Beides ist nicht ideal, aber du bekommst keine überraschende Rechnung. Die überraschenden Rechnungen entstehen bei Pro und Enterprise, wo die Nutzung über die enthaltene Menge hinaus gemessen wird.
Wird Vercels Bildoptimierung bei der Egress mitgezählt?
Ja. Optimierte Bilder, die über next/image bereitgestellt werden, zählen immer noch zur Egress. Die Ersparnis liegt in der Dateigröße: Du stellst ein 180KB WebP bereit statt eines 3MB JPEG, also ist die Egress pro Bild viel niedriger. Die Optimierung selbst ist das, was die Kosten senkt, nicht irgendeine spezielle Ausnahmeregelung.
Kann ich ein Custom CDN vor Vercel nutzen, um die Egress zu reduzieren?
Du kannst Cloudflares Proxy vor dein Vercel-Deployment setzen. Cloudflare cached Responses an seinem Edge, was bedeutet, dass Anfragen, die Cloudflares Cache treffen, gar nicht erst Vercel erreichen. Das kann sowohl die Egress als auch die Function Invocations erheblich reduzieren. Es gibt einige Vorbehalte bei Preview Deployments und Header-Verarbeitung, aber für Production ist das ein häufiger und legitimer Ansatz. Cloudflares Dokumentation zum Proxying behandelt das Setup.
Was ist die größte einzelne Ursache für unerwartete Vercel-Rechnungen?
Nach meiner Erfahrung: Bildbearbeitung. Entweder werden Bilder in voller Auflösung ohne Optimierung bereitgestellt, oder Bildoptimierungsrouten werden bei jeder Anfrage ohne angemessenes Caching aufgerufen. Kümmere dich zuerst um deine Bild-Pipeline, alles andere kommt danach.
Benachrichtigt dich Vercel automatisch, wenn die Nutzung in die Höhe schnellt?
Nicht standardmäßig. Du musst es konfigurieren. Es gibt keine sofort einsatzbereite Warnung, die sagt „du hast 80% deiner Bandbreite verbraucht." Das ist die Lücke. Stelle deine Ausgabenschwellen am gleichen Tag ein, an dem du deinen Produktionsdeployment einrichtest. Nicht später.
---
Vercel ist eine großartige Plattform. Ich nutze sie, Seahawk nutzt sie, und ich werde sie weiterhin für die richtigen Projekte empfehlen. Aber es ist ein abgerechneter Service, der auf echter Infrastruktur läuft, und die Preise spiegeln das wider. Die Entwickler, die durch überraschende Rechnungen zu Schaden kommen, sind fast immer diejenigen, die es wie ein kostenloses CDN behandelt haben und sich nie die Abrechnungseinstellungen angesehen haben. Fünf Minuten Konfiguration beim Deployment sparen dir einen sehr unangenehmen Anruf am Montagmorgen.
Weiterführende Lektüre: Luxury Jewelry Sites That Load in Under 1.5 Seconds, Core Web Vitals und WordPress-Geschwindigkeit.