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.