Ich habe in den letzten Jahren unzählige Next.js‑Projekte betrieben, deployed und optimiert — sowohl für eigene Prototypen als auch für Kund:innen. Eines der wiederkehrenden Probleme: die Hosting‑Kosten, speziell bei Platformen wie Vercel, steigen rapide, wenn man viele dynamische Seiten, Bilder und API‑Aufrufe hat. In diesem Artikel teile ich meine praktische Herangehensweise, mit der ich die Next.js‑Kosten halbiert habe: eine Kombination aus Edge Caching, gezielter Image‑Optimierung und On‑Demand Revalidation. Ich erkläre, warum die Kombination so effektiv ist und gebe konkrete Einstellungen, Header‑Tipps und Architektur‑Patterns, die du direkt übernehmen kannst.
Warum alleinige Optimierungen selten ausreichen
Viele Teams versuchen zuerst, nur Bilder zu optimieren oder nur CDN‑Caching zu aktivieren. Das hilft, aber oft bleibt ein großer Kostenfaktor: dynamische Serverless‑Invocations (Serverless Functions, Edge Functions) und häufige Image‑Resizes. Ein sinnvoller Ansatz reduziert gleichzeitig:
- die Anzahl der Serverless‑Ausführungen,
- die Größe und Anzahl ausgelieferter Assets,
- die Häufigkeit und Kosten für Origin‑Fetches.
Nur wenn Edge Caching, Image‑Optimierung und On‑Demand Revalidation zusammenarbeiten, entfaltet die Optimierung ihr volles Potenzial.
Edge Caching: meine Grundregeln
Edge Caching verlagert die Antwortlogik so nah wie möglich an die Nutzer:innen — das reduziert Latenz und Origin‑Traffic. Ich setze dabei auf ein paar Grundregeln:
- Cache so viel wie möglich am Edge, auch HTML für Seiten, die nicht super‑frequent aktualisiert werden.
- Nutze stale‑while‑revalidate für Seiten mit moderater Aktualisierungsfrequenz: das gibt schnelle Antworten und validiert im Hintergrund.
- Vermeide unnötig komplexe Cache Keys: schlichte Keys (URL + relevante Query Parameter) sind effizienter.
Konkrete Header, die ich verwende (Beispiel):
Cache‑Control: public, max‑age=60, s‑maxage=300, stale‑while‑revalidate=600
Diese Einstellung gibt 60 Sekunden Browser‑TTL, 5 Minuten CDN‑TTL und erlaubt bis zu 10 Minuten bedingtes Serving während der Revalidation. So sinkt die Origin‑Load deutlich.
Image‑Optimierung ohne Magie: Formate, Sizing, CDN
Bilder sind oft der größte Bandbreitenverbraucher. Ich optimiere auf drei Ebenen:
- Format: WebP oder AVIF dort nutzen, wo Browser es unterstützen. Moderne Image CDNs (Cloudinary, Imgix, Fastly Image, Vercel Image) liefern das automatisch.
- Responsive sizes: niemals eine große Originaldatei an mobile Geräte senden. Generiere Breakpoints und liefere passende Width/DPR.
- Edge‑Caching des optimierten Bildes: das resultierende WebP/AVIF wird am CDN‑Edge zwischengespeichert — kein erneutes Resizing pro Request.
Wenn du Next.js next/image nutzt, achte auf diese Punkte:
- Konfiguriere deviceSizes und imageSizes in next.config.js passend zu deiner UI.
- Setze unoptimized: false (Standard), aber stelle sicher, dass deine Image‑Domain von einer Image‑CDN unterstützt wird.
- Alternativ: verwende eine dedizierte Image‑CDN Integration (Cloudflare Images, Cloudinary) und gib statische URLs an — das entlastet Next.js Optimizer komplett.
On‑Demand Revalidation: Kontrolle statt Blindes Caching
Incremental Static Regeneration (ISR) ist großartig, aber „revalidate every X seconds“ allein kann ineffizient sein. On‑Demand Revalidation erlaubt dir, Seiten gezielt zu invalidieren und neu zu generieren, nur wenn es nötig ist. Damit lassen sich drastische Einsparungen erzielen:
- Reduzierte Build‑/Regeneration‑Anzahl → weniger Serverless‑Invocations.
- Kontrollierte Konsistenz: du revalidierst bei Content‑Updates (CMS Webhooks) statt bei jedem Timer‑Event.
Beispiel‑Flow, den ich nutze:
- CMS (Strapi / Contentful / Sanity) sendet Webhook bei Content‑Update.
- Webhook ruft eine Authenticated API Route in Next.js auf, die res.revalidate('/path') ausführt.
- Die Seite wird on‑demand neu generiert und am Edge gecacht.
Einfacher Tipp: kombiniere On‑Demand Revalidation mit conditional revalidation, also prüfe im Webhook Payload, welche Seiten tatsächlich betroffen sind, und revalidiere nur diese.
Praktische Architektur‑Kombination, die bei mir funktioniert
So sieht die Architektur aus, die meine Hostingkosten halbiert hat:
- Static Assets (JS/CSS) über CDN (z. B. Vercel / Cloudflare) mit aggressivem Edge‑Caching.
- Bilder über eine Image‑CDN (Cloudinary / Imgix / Vercel Image), mit AVIF/WebP und Breakpoints.
- HTML: ISR für selten aktualisierte Seiten + On‑Demand Revalidation für CMS‑gesteuerte Inhalte.
- API Endpoints: wenn möglich, als Edge Functions mit langer Cache‑TTL; kritische Backend‑Calls hinter einem Cache‑Layer (Redis / Cloudflare KV).
Messbare Einsparungen — meine Erfahrungswerte
Ich habe für ein mittelgroßes Projekt (2k tägliche Visits, 50 CMS‑Updates/Tag, ~200 Bilder) folgende Veränderungen gesehen:
| Vor Optimierung | Nach Optimierung |
|---|---|
| Origin‑Requests: ~30k/Tag | Origin‑Requests: ~8k/Tag |
| Serverless Invocations: ~12k/Tag | Serverless Invocations: ~3k/Tag |
| Bandbreite: 150 GB/Monat | Bandbreite: 45 GB/Monat |
Das führte zu fast 50–60% geringeren Hostingkosten bei Vercel. Wichtig: deine Zahlen werden anders aussehen — deswegen ist Messen vor und nach Änderungen Pflicht.
Was du messen solltest (und wie)
Bevor du etwas änderst, tracke:
- Anzahl und Kosten der Serverless/Edge‑Invocations (Provider Dashboard).
- Origin‑Requests pro Tag (CDN Analytics).
- Bandbreitennutzung speziell für Bilder.
- Cache Hit Ratio am Edge und beim Origin.
Diese Metriken zeigen dir, ob Caching und Image‑Offload wirken. Ich nutze Cloudflare Analytics + Provider‑Logs + ein einfaches Postgres/Prometheus‑Dashboard, um Trends zu visualisieren.
Fehlerquellen und Stolperfallen
Ein paar Dinge, die ich auf die harte Tour gelernt habe:
- Zu aggressive TTLs können zu veralteten Inhalten führen — kombiniere immer mit On‑Demand Revalidation oder Webhooks.
- Image‑Optimizer im Origin deaktivieren, wenn du eine Image‑CDN vorschaltest — sonst double resizing.
- Unbedachte Cache Keys (z. B. komplette Query‑Strings) führen zu niedrigen Cache‑Hits. Filtere nur relevante Parameter.
Wenn du möchtest, kann ich dir beim nächsten Schritt helfen: entweder indem ich deine next.config.js und Cache‑Headers durchsehe oder ein kleines Audit deiner Architektur mache. Sag mir kurz, wie dein Setup aussieht (Vercel/Cloudflare/Netlify, CMS, Image‑Handling) und ich gebe konkrete Konfig‑Empfehlungen.