Edge Computing Hosting: Latenz auf Millisekunden reduzieren
Jede Millisekunde zählt. Wenn deine Server in Frankfurt stehen und dein Nutzer in Tokio — das ist spürbar. Edge Computing bringt Logik dorthin, wo die Nutzer sind. Dieser Guide erklärt die Architektur, die Anbieter und die sinnvollen Use Cases.
Was ist Edge Computing? Die Idee erklärt
Traditionell: Request → zentraler Server (z.B. AWS Frankfurt) → Response. Der Nutzer in Tokio wartet auf einen Round-Trip von ~250ms.
Edge Computing: Request → nächster Edge-Node (Tokio, Singapur, Sydney) → Response. Latenz: unter 10ms.
Nutzer in Tokio
Nutzer in Tokio
Edge Functions sind serverlose, stateless Funktionen, die an Cloudflare-/Fastly-/Vercel-PoPs (Points of Presence) weltweit laufen. Sie sind kein Ersatz für zentrale Backend-Infrastruktur — sie ergänzen sie.
Edge ≠ Backend-Ersatz: Edge Functions sind für kurze, einfache Aufgaben gedacht (Auth-Checks, Redirects, A/B-Tests, Personalisierung, API-Gateway-Routing). Datenbankzugriffe, komplexe Business Logic und lang laufende Prozesse gehören ins zentrale Backend.
Use Cases: Wann Edge Computing wirklich Sinn macht
| Use Case | Edge Benefit | Beispiel |
|---|---|---|
| A/B-Testing | Variant-Zuordnung ohne Round-Trip | Edge setzt Cookie + Header, Backend rendert |
| Auth/Cookie-Checks | Login-Status prüfen, Token validieren, Requests ablehnen | Cloudflare Workers prüft JWT vor Cache |
| Geolocation-Routing | Nutzer zum nächsten Server/Dienst leiten | EU-Nutzer → EU-API, APAC → APAC-API |
| Redirects | SSL-Terminierung, Domain-Rewrite, Legacy-Routing | 301-Rewrites ohne Server-Hit |
| Bot-Detection | Schad-Traffic blocken BEVOR er den Backend erreicht | Challenge-Pages, CAPTCHA-Injection |
| API-Rate-Limiting | Zu viele Requests ablehnen, ohne Backend-Last | Edge-zählt Token-Bucket, reagiert inline |
| HTML-Personalisierung | Static-HTML-Cache mit Edge-Mutations (Header/Class inject) | Schnelle Pages + Personalisierung trotz Cache |
| LLM-API-Gateway | Request-Routing, Retry-Logic, Model-Switching | Edge-Router zu GPT-4 / Claude / Gemini |
Cloudflare Workers — Marktführer im Edge-Serverless
Cloudflare Workers laufen in ~300+ Rechenzentren weltweit. Jeder Request wird automatisch zum nächstgelegenen PoP geroutet. Execution Environment: V8 Isolates (keine VMs, keine Container) → Cold Start unter 5ms.
// workers/hello.js — Cloudflare Worker
export default {
async fetch(request, env, ctx) {
const url = new URL(request.url);
// Geolocation-basierte Weiterleitung
const country = request.cf.country;
if (country === 'DE' || country === 'AT' || country === 'CH') {
// EU-Nutzer → EU-Backend
return fetch(request);
}
if (country === 'JP' || country === 'KR' || country === 'SG') {
// APAC → APAC-Backend
const modifiedRequest = new Request(
request.url.replace('api.example.com', 'api-apac.example.com'),
request
);
return fetch(modifiedRequest);
}
// Rest → Default
return fetch(request);
}
};
//wrangler.toml
name = "geo-router"
main = "workers/hello.js"
compatibility_date = "2024-01-01"Workers mit KV (Key-Value Store) für Stateless Personalisierung
// Edge: Personalisierte Startseite basierend auf Nutzerpräferenzen
export default {
async fetch(request, env, ctx) {
const userId = getUserIdFromCookie(request);
if (!userId) {
// Unbekannter Nutzer → A/B-Test-Gruppe zuweisen
const group = Math.random() > 0.5 ? 'A' : 'B';
const response = await fetch(request);
const modifiedResponse = new Response(response.body, response);
modifiedResponse.headers.set('X-AB-Group', group);
modifiedResponse.headers.append('Set-Cookie', `ab_group=${group}; Path=/; Max-Age=${60*60*24*30}`);
return modifiedResponse;
}
// Nutzer-Preferences aus KV holen
const prefs = await env.KV.get(userId, 'json') || {};
const html = await fetch('https://origin.example.com/').then(r => r.text());
const personalized = html.replace('{{USER_NAME}}', prefs.displayName || 'Gast');
return new Response(personalized, {
headers: { 'Content-Type': 'text/html; charset=utf-8', 'Cache-Control': 'private' }
});
}
};Vercel Edge Functions
Vercel Edge Functions nutzen V8 Isolates (wie Cloudflare) — deployed auf das Vercel Edge Network. Nahtlose Integration mit Next.js Middleware. Besser für Frontend-lastige Teams, die bereits Vercel nutzen.
// middleware.ts — Vercel Edge Middleware (Next.js)
import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';
export function middleware(request: NextRequest) {
// Geolocation aus Header extrahieren
const country = request.geo?.country || 'DE';
const city = request.geo?.city || 'Frankfurt';
// Rewrite für lokalisierte Inhalte
const url = request.nextUrl.clone();
url.searchParams.set('geo_country', country);
url.searchParams.set('geo_city', city);
const response = NextResponse.rewrite(url);
// A/B-Test-Gruppe setzen
const abCookie = request.cookies.get('ab_group')?.value;
if (!abCookie) {
const group = Math.random() > 0.5 ? 'control' : 'variant';
response.cookies.set('ab_group', group, { maxAge: 60 * 60 * 24 * 30 });
response.headers.set('X-AB-Group', group);
} else {
response.headers.set('X-AB-Group', abCookie);
}
return response;
}
export const config = {
matcher: ['/', '/about', '/products/:path*'],
};Cloudflare vs. Vercel vs. Fastly vs. Vultr Edge — Vergleich
| Kriterium | Cloudflare Workers | Vercel Edge | Fastly Compute | Vultr Edge |
|---|---|---|---|---|
| Netzwerk | ~300 PoPs global | ~70 PoPs | ~300 PoPs | ~30 PoPs |
| Cold Start | <5ms (V8 Isolates) | <5ms (V8 Isolates) | ~50ms (WASM) | ~20ms |
| Sprachen | JS, TS, Python, Rust, C, C++ | JS, TS, Rust, Go (WASM) | JS, TS, Rust, C | JS, TS |
| Memory Limit | 128 MB (Free), 512 MB (Paid) | 128 MB | 256 MB | 256 MB |
| Execution Timeout | 30s (CPU time, nicht Wall-Clock) | ~50ms (Edge), 10s (Serverless) | 60s | 30s |
| KV Storage | Cloudflare KV (global, replicated) | Vercel KV (Redis) | Fastly KV Store | Vultr KV (Redis) |
| EdgesQL | Hyperdrive (Pg + SQLite at Edge) | — | — | — |
| Preis | Free: 100k req/d; $5/10M req | Free: 100k req/d; $20/500k req | Pay-per-use, teurer | Ab $10/Monat |
| Beste Integration | Cloudflare Proxy + Cache + R2 + D1 | Next.js + Vercel Postgres | Terraform / Configurable | Vultr Cloud Infrastructure |
Edge-Computing-Architektur: Hybrid-Ansatz
Production-Setup: Edge für alles, was schnell gehen muss; zentrales Backend für alles, was Zustand braucht.
# Cloudflare Pages + Workers + R2 + Hyperdrive (Postgres at Edge)
# Architektur:
# 1. Cloudflare Pages: Statisches Frontend (HTML/CSS/JS/Images aus R2)
# → Cache auf Edge, 100+ Länder, <50ms TTFB
# 2. Cloudflare Worker (Edge Middleware):
# → Auth, Geolocation-Routing, A/B-Tests, Rate Limiting
# → Requests ohne Auth können komplett aus Cache bedient werden
# 3. Cloudflare Hyperdrive (SQLite at Edge):
# → Sub-10ms Queries auf hottest data (Session, Cart, User-Prefs)
# → Fallback auf zentrales Postgres für komplexe Queries
# 4. Central Backend (Node.js auf VPS):
# → Business Logic, Payment, Datenbank-Writes
# → Async-Worker für Background-Jobs
# Request-Flow:
# Nutzer (Tokio)
# → Cloudflare Edge Node (Tokio)
# → Worker: Auth check, geolocation route
# → Cache HIT? → Return cached HTML
# → Cache MISS? → Origin (Frankfurt) fetch
# → Vor dem Response: Cache speichern (TTL 60s)
# → Edge-Response an Nutzer (fast)
# Kosten-Vergleich (vereinfacht):
# 1M Requests/Monat
# Cloudflare Workers: $0
# AWS Lambda (same traffic): ~$0.20
# Dedizierter VPS (same traffic): ~$20-60/MonatEdge + CDN = kein Widerspruch. CDN cached statische Assets (HTML, JS, CSS, Images). Edge Functions verändern dynamische Requests, cachen personalisierte Responses (mit Cache-Control: private/max-age=0). Kombination: statische Assets vom CDN (max-age=1y), dynamische Requests vom Edge Layer (no-store oder kurzes max-age).
Edge Functions richtig benchmarken
Nicht alle Edge-Latenzen sind gleich. Relevant: Time To First Byte (TTFB) — nicht nur Cold-Start.
- TCP-Triple-Handshake: Edge-PoP muss vom Nutzer-Standort aus erreichbar sein (Cloudflare hat Peering zu fast allen ISPs)
- TLS-Terminierung: Edge schließt TLS am PoP — spart Round-Trip zum Backend
- Origin-Latenz: Edge hilft nur bei Edge-eigenen Aufgaben. Datenbank-Calls gehen trotzdem quer über den Globus
Teste die Latenz von deinem Standort: curl -w "TTFB: %{time_starttransfer}s\n" https://workers.cloudflare.com/__zone-name__/
Limitierungen: Was Edge nicht kann
- Keine dauerhaften Verbindungen (WebSockets: theoretisch möglich, praktisch instabil über Edge-Nodes)
- Keine lang laufenden Prozesse — Limits bei 30-50ms CPU pro Request
- Kein Dateisystem — nur KV, Object Storage (R2, S3), Databases
- Kein Node.js/npm-Ökosystem — keine nativen Node.js-Module, nur V8-APIs
- Stateful Business Logic — bleibt im zentralen Backend
Edge Computing Spickzettel
- Edge ≠ Backend-Ersatz — Edge ist für Routing, Auth, Caching, Personalisierung; Business Logic bleibt zentral
- Cloudflare Workers ist Marktführer — 300+ PoPs, V8 Isolates (<5ms Cold Start), KV/D1/R2-Integration
- Vercel Edge Functions für Frontend-Teams, die bereits auf Vercel deployen — nahtlose Next.js-Integration
- Hybrid-Architektur: CDN cached statische Assets; Edge Functions verarbeiten dynamische Requests; zentraler Server für Datenbank und Business Logic
- Geolocation-Routing ist der einfachste Edge-Use-Case — redirigiere Nutzer zum nächstgelegenen Backend-Server
- A/B-Testing und Personalisierung auf Edge-Ebene → Header/Classes injectieren, ohne Cache zu brechen
- Hyperdrive (Cloudflare) und Vercel KV ermöglichen schnelle DB-Zugriffe aus Edge-Functions — SQLite at the Edge
- Benchmarks zuerst: Edge-Vorteile nur wenn Origin-Latenz das Bottleneck ist. Für intranationalen Traffic bringt Edge wenig.