Frisst Vercel dein Budget? Wie du die Kosten in React & Next.js wirklich senkst – ohne Optimierungs-Fanatismus

Vercel-Kosten explodieren oft durch Architekturentscheidungen, nicht die Plattform. So reduzierst du Next.js-Kosten ohne Architektur zu zerstören.

Frisst Vercel dein Budget?

Wie du die Kosten in React & Next.js wirklich senkst – ohne Optimierungs-Fanatismus

Vercel ist eine der besten Plattformen für React- und Next.js-Projekte. Schnelle Deployments, exzellente Developer Experience und moderne Edge-Infrastruktur.

Doch viele Teams erleben früher oder später dasselbe: Die Kosten steigen – schneller als das Business.

Wichtig vorweg: In den meisten Fällen ist nicht Vercel das Problem. Sondern Architekturentscheidungen, die zu Beginn sinnvoll wirkten und später teuer werden.

In diesem Artikel schauen wir uns an:

  • warum Vercel-Kosten plötzlich explodieren
  • was das Billing wirklich beeinflusst (und was nicht)
  • wie man Next.js effizient optimiert
  • wo Optimierung in schädlichen Fanatismus kippt

Wie Vercel abrechnet (vereinfacht)

Die wichtigsten Kostentreiber:

  1. Serverless- und Edge-Ausführungen
  2. SSR- und ISR-Rendering
  3. Middleware
  4. Builds
  5. Bandbreite (vor allem Bilder)
  6. Analytics & Logs

Der häufigste Fehler: Man schaut nur auf den Traffic, nicht auf die Rendering-Architektur.

Der größte Kostentreiber: Unnötiges SSR

Klassisches Szenario

  • Next.js App Router
  • Im Root-layout.tsx:
  • headers()
  • cookies()
  • auth()
  • draftMode()

Folge:

  • alles wird dynamisch
  • jeder Seitenaufruf kostet Geld
  • auch Googlebot und Preview-Requests

Selbst auf reinen Marketingseiten.

Die Lösung

Saubere Trennung der Bereiche:

  • Öffentliche Seiten → static oder ISR
  • App / Dashboard → SSR
  • Admin / Preview → SSR + draftMode

Beispiel:

export const dynamic = 'force-static'

oder

export const revalidate = 3600

Das allein spart oft den Großteil der Kosten.

Middleware: Unsichtbar, aber teuer

Middleware läuft bei jedem passenden Request:

  • Bots
  • Previews
  • Statische Seiten
  • Health-Checks

Häufige Fehlanwendungen

  • Redirects
  • i18n
  • Tracking
  • A/B-Tests
  • Marketing-Logik

Besserer Ansatz

  • Keine Middleware auf öffentlichen Seiten
  • Redirects über vercel.json
  • Auth nur im App-Bereich
"matcher": ["/app/:path*"]

ISR: Wenn Caching plötzlich teuer wird

ISR ist mächtig – aber gefährlich bei falscher Konfiguration.

Typische Probleme:

  • zu kurze revalidate-Zeiten
  • viele Seiten
  • häufige Invalidierungen

Warnsignale

  • revalidate: 60 auf SEO-Seiten
  • Cron-Jobs, die ISR triggern
  • CMS-Speichern löst Rebuilds aus

Empfehlungen

  • SEO-Seiten: 3600–86400
  • Blog / Cases: ISR + on-demand
  • Marketing ohne Updates: komplett statisch

Image Optimization: Sinnvoll, aber nicht gratis

Next/Image ist hilfreich, aber:

  • jede neue Größe = neue Transformation
  • mehrere Breakpoints vervielfachen Requests

Typische Fehler

  • zu viele responsive Größen
  • dynamische Dimensionen
  • kein CMS-Limit

Best Practices

  • feste Größen
  • gutes CDN-Caching
  • voroptimierte WebP / AVIF für Hero-Images

Builds: Der stille Kostentreiber

Jeder Build kostet Geld.

Häufige Ursachen

  • Preview-Deployments bei jedem Commit
  • Bots triggern Builds
  • CMS-Hooks rebuilden unnötig

Basis-Hygiene

  • Preview-Deployments begrenzen
  • keine Builds bei Draft-Content
  • Deploy-Hooks prüfen

Analytics und Overengineering

Analytics ist selten der Hauptgrund, aber:

  • serverseitiges Tracking
  • exzessive Logs
  • Debug-Modi

können Kosten unnötig erhöhen.

Faustregel

  • Marketing → Client-Side Analytics
  • Server-Side nur bei echtem Bedarf
  • Logs minimal halten

Wenn Optimierung zu Fanatismus wird

Ein sehr wichtiger Punkt.

❌ Schlechte Optimierung:

  • Architektur umbauen für 20 € Ersparnis
  • Developer Experience zerstören
  • unnötige Komplexität
  • SSR grundsätzlich verteufeln

✅ Gesunde Optimierung:

  • SSR nur dort, wo nötig
  • Middleware reduzieren
  • Caching verstehen
  • Kosten bewusst steuern

Wenn ein Produkt Umsatz macht, sollte Infrastruktur Wachstum ermöglichen, nicht blockieren.

Checkliste bei hohen Vercel-Kosten

  1. Dynamische APIs in öffentlichen Layouts?
  2. Middleware auf /?
  3. SSR auf Marketingseiten?
  4. revalidate-Werte
  5. Anzahl Builds
  6. Image-Optimierung
  7. Preview-Deployments
  8. CMS-Preview / Drafts
  9. Server-Side Analytics
  10. Bot-Traffic

Fazit

Vercel „frisst" kein Geld. Es rechnet ehrlich für Architekturentscheidungen ab.

In den meisten Fällen brauchst du:

  • kein Hosting-Wechsel
  • kein Kubernetes
  • kein Self-Hosting

Sondern:

  • klare Rendering-Grenzen
  • weniger Middleware
  • sauberes Caching

Optimierung ist ein Werkzeug. Fanatismus schadet dem Produkt.