Was ist Edge Rendering und warum ist es wichtig

Ein traditioneller Webserver wird in einer einzigen geografischen Region betrieben. Nutzer in der Nähe dieser Region erhalten schnelle Antworten, während Nutzer in großer Entfernung unter erheblicher Latenz leiden — bei einer Inhaltsanfrage eines Nutzers in Tokio an einen Server in US-East vergehen beispielsweise mehr als 200 ms für die Hin- und Rücklaufzeit, bevor das erste Byte eintrifft.

Ein Content Delivery Network (CDN) cached statische Dateien wie Bilder, CSS und JavaScript an Dutzenden Points of Presence (PoPs) weltweit und liefert sie vom nächstgelegenen Standort aus. Ein traditionelles CDN kann jedoch keinen Code ausführen — es kann nur vorab erstellte, statische Inhalte ausliefern.

Eine Edge-Runtime führt JavaScript weltweit an CDN-PoPs aus und vermeidet bei dynamischen Anfragen den Roundtrip zum Ursprungsserver. Statt die Anfrage an einen einzelnen Server weiterzuleiten, wird sie am nächstgelegenen PoP verarbeitet — oft in derselben Stadt —, wodurch sich die Latenz drastisch verringert.

Cloudflare Workers führen JavaScript mithilfe von V8-Isolates an mehr als 300 Standorten weltweit aus. Im Gegensatz zu Serverless-Funktionen wie Lambda und Cloud Run haben Workers nahezu keine Cold Starts — die Startzeit wird in Mikrosekunden statt in den für Lambda typischen 100 oder mehr Millisekunden gemessen —, da sie V8-Isolates wiederverwenden, anstatt Container zu starten.

Edge-Rendering bedeutet, Ihre React-Anwendung am Edge-PoP zu rendern, der jedem Nutzer am nächsten liegt, und das resultierende HTML sofort auszuliefern. Der Nutzer in Tokio erhält eine vollständig gerenderte HTML-Seite von einem PoP in Singapur und nicht von einem Server in Virginia.

Eine standardmäßige SSR-Anwendung, die von US-East aus bereitgestellt wird, benötigt möglicherweise 400 ms bis nach Tokio (200 ms Netzwerk + 200 ms Server-Rendering). Beim Edge-Rendering erfolgt das Rendering in Singapur, wodurch sich die Netzwerklatenz auf 30 ms verringert und das HTML insgesamt in weniger als 100 ms ausgeliefert wird — eine vierfache Verbesserung der wahrgenommenen Ladezeit.

Edge-Runtimes sind keine vollständigen Node.js-Umgebungen. Cloudflare Workers verbieten die Node.js-Kern-APIs fs, net und crypto, begrenzen die CPU-Zeit auf 50 ms pro Anfrage (kostenpflichtige Tarife erlauben mehr), schränken den Speicher ein und bieten keinen Dateisystemzugriff. Diese Einschränkungen erfordern eine durchdachte Architektur.

Mehrere Plattformen bieten Edge-Runtimes an: Vercel Edge Functions (basierend auf demselben V8-Isolate-Modell), Deno Deploy (verwendet die Deno-Runtime am Edge) und Fastly Compute (verwendet WebAssembly). Sie unterscheiden sich bei API-Kompatibilität, weltweiter Abdeckung und Preismodellen.

Edge-Rendering ist besonders nützlich für Inhalte, die größtenteils statisch sind, aber eine gewisse Personalisierung benötigen: Marketingseiten mit A/B-Testvarianten, Landingpages mit geografisch ausgerichteten Inhalten und Blogbeiträge mit nutzerspezifischen Elementen wie Anmeldestatus oder Sprache. Hochdynamische, datenbankintensive Seiten profitieren weniger davon.

Lambda- (und Cloud-Run-)Funktionen starten Container, laden Ihren Code herunter, initialisieren die Runtime und führen ihn anschließend aus — dadurch entstehen Cold Starts von 100 bis 1.000 ms. Workers verwenden bereits laufende V8-Isolates wieder, wodurch Cold Starts mit weniger als 5 ms praktisch nicht wahrnehmbar sind.

Die meisten Anwendungen im Produktionseinsatz verwenden Edge-Rendering gezielt: Das Edge rendert schnelle, größtenteils statische Seiten, während ein regionaler Server authentifizierte und datenbankintensive Vorgänge übernimmt. Dieser hybride Ansatz bietet die Vorteile der geringeren Latenz beim Edge-Rendering, ohne dessen Einschränkungen umgehen zu müssen.

Warum haben Cloudflare Workers im Vergleich zu AWS Lambda nahezu keine Cold Starts?

Beim Edge-Rendering wird JavaScript weltweit an CDN-PoPs ausgeführt. Dadurch entfallen Roundtrips zum Ursprungsserver und die Latenz wird drastisch reduziert. Cloudflare Workers überzeugen mit auf V8-Isolates basierenden Cold Starts im Mikrosekundenbereich an mehr als 300 Standorten. Die Nachteile sind jedoch erheblich — keine Node.js-APIs und begrenzte CPU-Zeit —, weshalb sich Edge-Rendering am besten für Marketingseiten und personalisierte, aber größtenteils statische Inhalte eignet und weniger für stark datenbankabhängige Seiten.