Nachhaltige Vercel-Deployments: Developer-Guide zur CO₂-Reduktion

• Das Problem: Vercel Functions laufen standardmäßig in Washington D.C. (400g CO₂/kWh, 8% Erneuerbare)
• Quick fix: Regionen ändern zu Stockholm (20g CO₂/kWh, 60% Erneuerbare) oder Portland (194g CO₂/kWh, 66% Erneuerbare) via vercel.json
• Impact: 95% weniger Emissionen, oft bessere Latenz für EU-User, GDPR-Compliance-Vorteile
• Trade-off: Achte auf die Locations deiner Datenquellen(n), um Extra-Roundtrips zu vermeiden
• Bonus: Richtiges Caching eliminiert die Function-Execution komplett (null zusätzliche Emissionen durch Compute)

Wir sind große Fans von Next.js und Vercel - die Developer Experience ist einfach sehr gut: CI/CD, Preview Deployments, Zero-Config Hosting. Nachdem wir das Green Software Manifesto unterzeichnet und uns als B Corp dem Bundesverband Green Software angeschlossen haben, stellten wir uns die Frage: Können wir unsere Vercel Workloads auf saubereren Stromnetzen betreiben, ohne Performance oder Kosten zu gefährden?

Kurze Antwort: Ja. Die Wahl der richtigen Regionen hat unsere Apps grüner, oft schneller und manchmal sogar günstiger gemacht. Wie wir das im Detail gemacht haben, lest ihr hier:

Standardmäßig werden alle Vercel Node.js Functions in Washington D.C. (iad1) ausgeführt, das auf einem der schmutzigsten Stromnetze im Netzwerk läuft:

• 400g CO₂/kWh
• 8% erneuerbare Energie
• 🙀 Hauptsächlich Kohle, Gas und Atomkraft

Strommix: Washington DC (2024, electritymaps.com)

Jede API Route, jedes Server-Side Rendering und jede Datenbank-Query läuft dort, es sei denn, du konfigurierst es anders. Das ist besonders relevant für User Bases außerhalb der USA. Als europäisches Unternehmen mit 80% der Visits aus Deutschland bedeutet das, dass Serverless Functions standardmäßig in den USA ausgeführt werden - was einen 12.000 km Roundtrip pro Function Call bedeutet.

Glücklicherweise bietet Vercel Optionen, um die Standard-Region(en) zu ändern.

Die Terminologie von Vercel kann verwirrend sein. Lass uns klären, was Edge POPs und Function Regions tatsächlich bedeuten:

Quelle: https://vercel.com/docs/cdn

Die 126 POPs (Points of Presence) sind eigentlich das, was ich als Edge Endpoints bezeichnen würde, da sie global verteilt sind, der erste Touchpoint eines Requests und damit am nächsten am User.

Die 19 Edge Regions sind die einzigen Compute-fähigen Regionen "where your code runs close to your data", weshalb ich vorschlagen würde, sie eher Function Regions statt Edge Regions zu nennen.

Siehe Region List und Runtimes für mehr Hintergrund.

Das bedeutet...

POPs

• (CDN) Cache: Static Assets, cached Responses
• Edge Functions: Kann Edge Functions mit einer limited Runtime ausführen (ähnlich wie Cloudflare Workers)

Edge Function Region

• Serverless Functions: Hier werden Serverless Functions (Node.js, Go, Python, Ruby) ausgeführt
• Data Cache: HTTP Calls, die innerhalb deiner Function gemacht werden, werden genau in dieser Region gecacht

Quelle: https://vercel.com/blog/life-of-a-vercel-request-what-happens-when-a-user-presses-enter

Requests kommen am nächsten POP (Edge) an und hier liegen die gecachten Daten:

Vercel stellt klar, dass "Static files are automatically cached at the edge on Vercel's CDN for the lifetime of the deployment after the first request."

Damit es nicht zu einfach wird, gibt es noch drei weitere Begriffe, die mit dem Edge Cache zusammenhängen:

• Fast Origin Transfer: Der Data Transfer zwischen Vercels CDN (POP) und Vercel Compute (Function Region)
• Fast Data Transfer: Der Data Transfer zwischen Vercels CDN (POP) und den End Users deiner Site (Browser)
• ISR: Incremental Static Regeneration: (ISR) erlaubt es dir, Content auf deiner Site zu erstellen oder zu updaten, ohne ein Redeployment zu machen, der dann am Edge (POP) gecacht wird

Du kannst die Response Headers checken, um zu sehen, ob ein Request aus dem Cache kam und welcher POP für die Auslieferung zuständig war:

In diesem Fall ist "fra1" Frankfurt, Deutschland. Siehe Region List

Der Data Cache befindet sich in der Function Region, die du definiert hast. Alle fetch Calls werden zum Beispiel an der gleichen Location wie deine Function gecacht. Jede Region hat allerdings ihren eigenen Cache. Ein gecachter Fetch Call in Frankfurt ist nicht in Stockholm verfügbar.

Du kannst das selbst auf Vercel nachschauen: Observability > Data Cache

Jetzt kommen wir zum Kern dieses Guides: wo dein Compute tatsächlich läuft. Hier hast du die meiste Kontrolle über deinen Carbon Footprint und hier machen regionale Entscheidungen den größten Unterschied.

Quelle: https://vercel.com/docs/cdn

Vercel hat drei Arten von Compute, jede mit unterschiedlichen Carbon-Implikationen:

Der Routing Flow:

• Request trifft nächsten PoP (von 126 weltweit)
• Static Content wird aus dem Cache ausgeliefert, falls verfügbar
• Edge Functions laufen am PoP
• Node.js Functions routen zu deiner konfigurierten Region (Function Region)

☝️ Vercel sagt: "We recommend migrating from edge to Node.js for improved performance and reliability." (https://vercel.com/docs/functions/runtimes)

Steps 3 & 4 sind das, was du kontrollierst. Mit Vercels Empfehlung zur Migration von Edge zu Node.js Runtime wird die regionale Optimierung noch wichtiger.

Debugging Request Flow:

Quelle: https://vercel.com/blog/life-of-a-vercel-request-navigating-the-edge-network

Du kannst auch im Vercel Dashboard nachschauen: Observability → Data Cache und Regions, um dein Setup zu verifizieren.

💡 Wer noch tiefer abtauchen möchte, dem empfehle ich diese Blogpost-Serie von Vercel:

• Life of a Vercel request: Navigating the Edge Network
• Life of a Vercel request: What happens when a user presses enter

Wir haben EU- und US-Vercel Compute Regions analysiert und dabei 2024 Annual Average Data von ElectricityMaps verwendet (abgerufen September 2025).

Stockholm (arn1) ist der absolute Champion mit 95% weniger Emissionen als Washington D.C. und einer der saubersten Compute-Regions weltweit.

Portland (pdx1) reduziert Emissionen um 51% verglichen mit dem Washington-Default, während du in den USA bleibst.

Es gibt drei Wege, deine Function Region(s) zu konfigurieren:

Siehe https://vercel.com/docs/cli/deploy#regions

Project Settings → Functions → Function Regions → Select Regions

Note: Per-route preferredRegion ist limitiert auf Edge Functions. Siehe Vercel Edge Runtime - Regions

Es reicht nicht die sauberste Region zu wählen - berücksichtige deine Datenquellen und User Location

Während dieser Default für US-zentrische Anwendungen Sinn macht, ist er möglicherweise nicht optimal für Unternehmen mit anderen User-Verteilungen oder Data Residency Anforderungen (Stichwort DSGVO!).

Die Distanz zwischen deinen Usern, Function Regions und Datenquellen hat erheblichen Impact sowohl auf Carbon Emissions als auch auf Latenz.

Um die richtige Region(en) auszuwählen, musst du zwei Fragen beantworten:

Schau dir deine Analytics an und versuche, Regionen zu finden, die so nah wie möglich, so grün wie möglich und vollständig konform mit deinen rechtlichen Requirements sind (GDPR → EU-only).

Beispiel: Wenn der Großteil deines Traffics aus Deutschland kommt, bedeutet das Default Routing nach Washington 12.000km Roundtrip pro Function Call und eine mögliche GDPR-Verletzung.

Du kannst Vercels eigene Observability Notebooks nutzen, um die POP-Verteilung nachzuschauen.

Deine Function könnte verschiedene Datenquellen aufrufen, um die Daten zu bekommen, die sie für Rendering/Response braucht. Diese sollten möglichst nah an deiner Function Location sein.

Beispiel: Wenn der Großteil deines Traffics aus Deutschland kommt, deine Function so eingestellt ist, dass sie in Washington läuft, und die Datenbank in Frankfurt läuft, hast du noch einen weiteren 12.000 km Roundtrip on top.

API Endpoints wie der GraphQL Endpoint deines liebsten Headless CMS (unseres ist DatoCMS) werden von der Function aufgerufen. Versuche herauszufinden, wo deren Server laufen. In den meisten Fällen sind diese APIs global verteilt und gecacht, sodass du vielleicht nur den Edge Node findest, den dein Fetch Call erreicht. Das ist in Ordnung, denn in diesem Fall musst du dich selbst nicht darum kümmern. Zusätzlich werden die meisten Fetch Calls von Vercel im Data Cache in der gleichen Region gecacht, in der deine Function ausgeführt wird.

Du kannst die externen APIs und den Cache Status in den Vercel Logs sehen.

Moderne Cloud-Datenbanken bieten dir die Option, die Region zu definieren und/oder Read Replicas in mehreren Regionen zu definieren. Das ist besonders wichtig, wenn es um GDPR und Compliance geht.

Schauen wir uns drei bekannte Beispiele aus dem Vercel-Universum an:

Vercel vs Database Provider Regional Coverage Matrix (September 2025)

• ✅ Direct Regional Match - Provider hat ein Rechenzentrum in der gleichen oder sehr nahen Location
• ⚪ Nearby Region - Provider bedient diese Region von einer nahen Location aus (höhere Latenz)
• ❌ No Coverage - Provider hat keine Präsenz in dieser Region oder in der Nähe

Quellen:

• https://supabase.com/docs/guides/platform/regions
• https://upstash.com/docs/common/concepts/global-replication#available-regions
• https://neon.com/docs/introduction/regions

Betrachte eine deutsche E-Commerce-Site mit dem Default Setup (Functions in Washington, D.C., Database in Frankfurt):

• User Request: Berlin → Frankfurt (POP) → Washington, D.C. (~6.550 km)
  • Database Query: Washington, D.C. → Frankfurt (~6.550 km)
  • Database Response: Frankfurt → Washington, D.C. (~6.550 km)
• Response to User: Washington, D.C. → Frankfurt (POP) → Berlin (~6.550 km)

Distanz gesamt: ~26.000 km über den Ozean für einen einzigen Request, der Database-Daten braucht.

Impact schätzen (nur Network):

• Latency Overhead: ~200–260 ms zusätzlich (vs. ~10–20 ms, wenn alles in Frankfurt wäre)
• Carbon Overhead: ~0,12 g CO₂ pro Request (≈1 MB crossing the Atlantic; skaliert linear)
• At Scale: 10M Requests/Monat ≈ ~14 t CO₂/Jahr allein durch Transmission (≈~18 t/Jahr bei 0,15 g/Request)
• Fixed Networks nutzen etwa 0,05 Wh pro GB·km. Bei angenommenen ~1 MB total, die pro Request über den Atlantik gehen (Request + DB Roundtrip + Response), sind das ≈ 0,33 Wh ⇒ ~0,12 g CO₂ pro Request (bei ~360 g CO₂/kWh). Payload skaliert linear: ein schlankes ~0,35 MB wären ~0,04–0,05 g; ~1,3 MB ≈ ~0,15 g.

Durch Co-location von Functions und Daten in Frankfurt eliminierst du die transatlantischen Endpunkte und reduzierst Latenz und Carbon um bis zu ~85–90%.

Wichtig: Cache Hits umgehen Function Execution und Long-haul Transit, sodass zusätzliches Network CO₂ effektiv null ist, unabhängig von der Region. Richtige Cache-Control Headers können sowohl Emissionen als auch Latenz dramatisch reduzieren und sind immer empfehlenswert!

Vercels Sustainability-Ansatz ist begrenzt - ihre Green Energy Policy delegiert hauptsächlich an AWS und Microsoft. Wir würden uns wünschen, dass Vercel Nachhaltigkeit ernst nimmt, per-Region Sustainability Metrics veröffentlicht und es ins Green Web Directory schafft.

Aber während wir darauf warten, ist die Optimierung der Regionen ein konkreter Schritt, den Developer heute machen können.

Quellen:

• Vercel Function Regions Documentation
• Vercel CDN Documentation
• AWS 2023 Sustainability Report
• ElectricityMaps - Live CO₂ Data
• Green Software Manifesto

Fragen oder Erfahrungen? Immer her damit!