Vad är edge-rendering och varför är det viktigt

En traditionell webbserver finns i en enda geografisk region. Användare nära den regionen får snabba svar, men användare långt bort drabbas av betydande fördröjning — en användare i Tokyo som begär innehåll från en US-East-server får ytterligare 200+ ms tur-och-retur-tid innan den första byten anländer.

Ett Content Delivery Network (CDN) cachelagrar statiska filer som bilder, CSS och JavaScript vid dussintals Points of Presence (PoP:er) världen över och levererar dem från den närmaste platsen. Ett traditionellt CDN kan däremot inte köra kod — det kan bara leverera förbyggt, statiskt innehåll.

En edge-runtime kör JavaScript vid CDN:s PoP:er över hela världen och eliminerar tur-och-retur-resan till ursprungsservern för dynamiska begäranden. I stället för att dirigera begäran till en enda server hanteras den vid den PoP som ligger närmast användaren — ofta i samma stad — vilket minskar fördröjningen avsevärt.

Cloudflare Workers kör JavaScript med V8-isolat på över 300 platser globalt. Till skillnad från serverlösa funktioner (Lambda, Cloud Run) har Workers nästan inga cold starts — de mäts i mikrosekunder i stället för de 100+ millisekunder som är typiska för Lambda — eftersom V8-isolat återanvänds i stället för att containrar startas.

Edge-rendering innebär att React-applikationen renderas på serversidan vid den edge-PoP som ligger närmast varje användare och att den resulterande HTML-koden levereras omedelbart. Användaren i Tokyo får en färdigrenderad HTML-sida från en PoP i Singapore, inte från en server i Virginia.

En vanlig SSR-app som levereras från US-East kan ta 400 ms att nå Tokyo (200 ms nätverk + 200 ms serverrendering). Med edge-rendering sker renderingen i Singapore, vilket minskar nätverksfördröjningen till 30 ms och levererar HTML-koden på totalt under 100 ms — en fyrfaldig förbättring av den upplevda laddningstiden.

Edge-runtime-miljöer är inte fullständiga Node.js-miljöer. Cloudflare Workers tillåter inte Node.js-kärn-API:er (fs, net, crypto), begränsar CPU-tiden till 50 ms per begäran (betalda planer tillåter mer), begränsar minnet och saknar åtkomst till filsystemet. Dessa begränsningar kräver en genomtänkt arkitektur.

Flera plattformar erbjuder edge-runtime-miljöer: Vercel Edge Functions (byggt på samma V8-isolatmodell), Deno Deploy (använder Deno-runtime vid edge) och Fastly Compute (använder WebAssembly). De har olika API-kompatibilitet, global täckning och prismodeller.

Edge-rendering är mest användbart för innehåll som till största delen är statiskt men behöver viss personalisering: marknadsföringssidor med A/B-testvarianter, landningssidor med geografiskt målinriktat innehåll och blogginlägg med användarspecifika delar (inloggat läge, språk). Mycket dynamiska, databasintensiva sidor har mindre nytta av det.

Funktioner på Lambda (och Cloud Run) startar containrar, laddar ner koden, initierar runtime-miljön och kör sedan koden — vilket leder till cold starts på 100–1000 ms. Workers återanvänder V8-isolat som redan körs, vilket gör cold starts i praktiken osynliga och kortare än 5 ms.

De flesta produktionsappar använder edge-rendering selektivt: edge-miljön renderar snabba, huvudsakligen statiska sidor medan en regional server hanterar autentiserade, databasintensiva åtgärder. Denna hybridmetod ger fördelarna med edge-rendering utan att behöva kämpa mot dess begränsningar.

Edge-rendering kör JavaScript vid CDN:s PoP:er över hela världen, eliminerar turer till ursprungsservern och minskar fördröjningen avsevärt. Cloudflare Workers utmärker sig med kallstarter på mikrosekundnivå tack vare V8-isolat, på över 300 platser. Avvägningarna är verkliga — inga Node.js-API:er och begränsad CPU-tid — vilket gör edge-rendering bäst lämpat för marknadsföringssidor och personaliserat men huvudsakligen statiskt innehåll, snarare än tunga databaskopplade sidor.