I september 2017 tillkännagav Cloudflare Workers, och i februari 2018 öppnades betan för alla. Idén var att låta utvecklare köra JavaScript-kod på Cloudflares nätverk, som då fanns på drygt hundra orter runt världen och i dag på över 300. Istället för att varje request skulle resa till en central server i Frankfurt eller Virginia, kunde koden exekveras på den nod som låg närmast användaren. Det var inte ett nytt koncept. CDN-leverantörer hade servat statiska filer från edge-noder i åratal, men att köra logik där ute var något annat.
Sedan dess har edge computing blivit ett av de mest använda buzzorden i webbutveckling. Vercel lanserade Edge Functions, Deno Deploy byggde en hel plattform kring konceptet, och varje hosting-leverantör har någon variant av edge-körningsmiljö i sitt erbjudande. Men under ytan av marknadsföring och hype finns en ganska enkel fråga: vad ger det dig i praktiken, och när är det värt besväret?
Vad edge computing innebär
Edge computing för webben handlar om en sak: att flytta exekvering av kod närmare slutanvändaren. Istället för att en request från en besökare i Tokyo måste resa hela vägen till en server i Europa, processas den på en nod i eller nära Tokyo.
Det traditionella upplägget ser ut så här: en användare gör en request, den routas till din origin-server (som kanske står i eu-west-1 på AWS), servern kör din kod, hämtar data från databasen, bygger ihop ett svar och skickar tillbaka det. Varje steg tar tid, och den fysiska distansen mellan användare och server är en faktor som ingen mängd optimering kan eliminera helt. Ljusets hastighet i fiberkabel är ungefär 200 000 km/s, och en tur-och-retur mellan Stockholm och Sydney tar runt 300 ms bara i nätverkslatens.
Med edge computing placeras delar av din logik på noder som ligger geografiskt nära användaren. Det kan vara en hel server-side rendering-pipeline, en middleware som hanterar autentisering, eller en enkel redirect-logik. Poängen är att minska antalet mil som data behöver resa innan användaren ser ett svar.
Det som gör edge-miljöer annorlunda jämfört med att bara ha servrar i flera regioner är exekveringsmodellen. Edge-funktioner startar extremt snabbt, hanterar en request och avslutas. De delar inte minne mellan requests på samma sätt som en traditionell server. Det gör dem lämpliga för korta, fokuserade uppgifter.
Hur de stora plattformarna gör det
Det finns tre dominanta aktörer för edge computing i webbutvecklingsvärlden, och de fungerar på liknande men inte identiska sätt.
Cloudflare Workers
Cloudflare Workers var tidigt ute och är fortfarande den mest utbredda plattformen. Tekniskt bygger de på V8 isolates, samma JavaScript-motor som Chrome använder. Varje Worker körs i en isolerad V8-instans, inte i en container eller virtuell maskin. Det betyder att uppstartstiden är extremt låg, ofta under en millisekund, jämfört med container-baserade lösningar som kan ta hundratals millisekunder att kalla starta.
Workers körs på över 300 datacenter globalt. Free-planen ger dig 10 ms CPU-tid per request, medan betald plan (5 USD/månad) ger 30 sekunder CPU-tid som standard, och upp till 5 minuter om man höjer gränsen. Minnesgränsen är 128 MB. Du har tillgång till Web Standard APIs (fetch, Request, Response, crypto, streams) men inte till Node.js fullständiga API. Ingen fs, ingen child_process, inget net.
Cloudflare har byggt ett helt ekosystem runt Workers: KV (key-value storage), R2 (objektlagring kompatibel med S3 API), D1 (SQLite-databas), Durable Objects (stateful objekt som lever på en specifik nod), och Queues. Det ger dig möjlighet att bygga relativt komplexa applikationer som lever helt på edge.
Vercel Edge Functions
Vercel Edge Functions använder samma typ av V8 isolate-modell. Sedan juni 2025 körs de som Vercel Functions med Edge-runtime, och Vercel avråder från fristående Edge Functions i nya projekt. Styrkan ligger i integrationen med Next.js och Vercels deployment-pipeline.
I praktiken aktiverar du Edge-runtimen genom att lägga till export const runtime = 'edge' i en Next.js route handler eller middleware.
Vercels middleware, alltså koden som körs innan en request når din route, körs alltid på edge. Det gör den lämplig för saker som geolocation-baserade redirects, A/B-testning, autentiseringskontroller och request-rewriting. Men begränsningarna är desamma: ingen fullständig Node.js runtime, storleksbegränsningar på koden, och execution time limits.
Deno Deploy
Deno Deploy tar ett lite annorlunda grepp. Plattformen bygger på Deno-runtimen (skapad av Ryan Dahl, samma person som skapade Node.js) och använder också V8 isolates. Den körs i ett antal regioner globalt, med PoPs i bland annat Europa, Nordamerika och Asien.
Det som skiljer Deno Deploy är att det kommer med inbyggd KV-lagring (Deno KV), stöd för npm-paket via npm:-specifiers, och en runtime som är mer kompatibel med Web Standards från start. TypeScript fungerar utan extra konfiguration.
Deno Deploy marknadsförs med noll cold starts, vilket i praktiken innebär att V8 isolate-modellen ger uppstartstider som är så korta att de inte märks i normal användning.
Mätbar skillnad: TTFB i verkligheten
Teori är en sak, men vad ger edge computing i mätbara termer? TTFB (Time To First Byte) är det mest relevanta mätvärdet här. Det mäter tiden från att en request skickas tills det första bytet av svaret kommer tillbaka.
Tänk dig ett scenario: du har en Next.js-sajt med en origin-server i Frankfurt (eu-central-1). En användare i Stockholm gör en request.
Utan edge (origin i Frankfurt): Request reser från Stockholm till Frankfurt (~1200 km), servern processar requesten (säg 50 ms för en enkel SSR-sida), svaret reser tillbaka. Nätverkslatensen tur-och-retur är ungefär 20-30 ms. Total TTFB: runt 70-100 ms.
Det är helt okej. Men vad händer med en användare i Singapore?
Utan edge (origin i Frankfurt, användare i Singapore): Nätverkslatensen tur-och-retur mellan Singapore och Frankfurt är runt 250-350 ms. Lägg till 50 ms serverprocessering. Total TTFB: 300-400 ms. Om servern dessutom behöver hämta data från en databas i en annan region kan det bli 500-800 ms.
Med edge (kod körs på närmaste nod): Om din edge-funktion kan svara direkt (med cachad data eller enkel logik) sjunker TTFB till 20-50 ms oavsett var användaren sitter. Om edge-funktionen däremot behöver prata med din databas i Frankfurt försvinner en stor del av vinsten, för requesten måste ändå resa till Frankfurt och tillbaka.
Det sista är en viktig poäng som ofta utelämnas i marknadsföring. Edge computing minskar latensen mellan användare och exekveringsmiljö, men det minskar inte latensen mellan exekveringsmiljö och din datakälla. Om din edge-funktion behöver hämta data från en databas som bara finns i en region, flyttar du bara flaskhalsen.
Ungefärliga storleksordningar:
- Statiskt CDN-cachat innehåll: 10-30 ms TTFB globalt (det här behöver du inte edge-funktioner för, ett vanligt CDN fixar det)
- Edge-funktion med inbyggd logik (inga externa anrop): 20-60 ms TTFB globalt
- Edge-funktion som anropar databas i en region: 100-400 ms TTFB beroende på avstånd till databasen
- Traditionell server i en region: 50-800 ms TTFB beroende på avstånd till servern
Mönstret är tydligt: edge ger störst vinst antingen när svaret kan genereras utan externa dataanrop, eller när datakällan också är distribuerad (som Cloudflare KV eller en globalt replikerad databas).
Begränsningarna
Edge-miljöer är avsiktligt begränsade, och begränsningarna påverkar vad du kan bygga.
Ingen fullständig Node.js runtime
Det här är den största praktiska begränsningen. Edge-funktioner körs i V8 isolates med Web Standard APIs, inte i Node.js. Det betyder att du inte har tillgång till:
fs: ingen filsystemsåtkomstchild_process: kan inte köra externa processernet/dgram: inga raw socketscryptoi sin fulla Node-variant (men Web Crypto API finns)
Många npm-paket beror på dessa APIs och fungerar inte i edge-miljöer. ORMs som Prisma har behövt bygga speciella edge-kompatibla varianter. Bibliotek som använder fs under huven (vanligare än man tror) kraschar direkt.
Exekveringstidsbegränsningar
Cloudflare Workers free plan: 10 ms CPU-tid. Det är extremt lite. Betald plan ger 30 sekunder som standard och upp till 5 minuter, men det är fortfarande en hård gräns. Vercel Edge Functions har liknande begränsningar.
Det här utesluter tunga beräkningar, komplex bildbearbetning, och långa processer. Om din applikation behöver mer än några sekunder av CPU-tid är edge fel plats.
Minnesbegränsningar
128 MB per isolate på Cloudflare Workers. Det räcker för de flesta request-response-scenarion, men om du försöker ladda in stora dataset i minnet eller använda minnesintensiva bibliotek slår du i taket.
Storleksgränser på koden
Cloudflare Workers tillåter maximalt 10 MB komprimerad storlek (med betald plan, 3 MB free). Det kanske låter mycket, men om du bundlar in stora beroenden kan du nå gränsen.
Databasanslutningar
Traditionella databasanslutningar bygger på TCP-connections som hålls öppna. Edge-funktioner lever inte länge nog för connection pools, och varje isolate kan inte dela connections. Lösningen har blivit HTTP-baserade databasproxyer (som Neon med deras serverless driver, PlanetScale med deras fetch-baserade driver, eller Prisma Accelerate) men det lägger till ett extra lager.
Cold starts
V8 isolates startar på en bråkdel av en millisekund till några millisekunder, och Cloudflare förladdar dessutom Workern medan TLS-anslutningen sätts upp. Cold starts i container-bemärkelsen, hundratals millisekunder till sekunder, förekommer i praktiken inte.
Vilka sajter som tjänar på edge
Givet begränsningarna, vilka typer av sajter och applikationer drar nytta av edge computing?
E-handel med internationell trafik
Om du säljer till kunder i flera världsdelar och har dynamiskt innehåll (prisanpassning per region, lagerstatusar, personaliserade rekommendationer) kan edge-funktioner ge märkbar förbättring. En kund i Australien som slipper vänta 400 ms extra på varje sidladdning kommer att ha en bättre upplevelse. Multiplicera det med varje sida de laddar under ett besök, och skillnaden blir påtaglig.
API-gateways och routing
Edge är utmärkt för att hantera routing-logik, rate limiting, och autentiseringskontroller. Istället för att en icke-autentiserad request reser hela vägen till din origin-server bara för att få ett 401-svar, kan edge-funktionen fånga den direkt. Cloudflare Workers används ofta som API-gateways som sitter framför en origin-server och hanterar caching, routing och säkerhet.
Personalisering och A/B-testning
Ett av de mest praktiska användningsområdena för edge-funktioner är att personalisera innehåll utan att offra cachbarhet. Traditionellt är personaliserat innehåll svårt att cacha, eftersom varje användare ser olika saker och du inte kan använda ett CDN effektivt.
Med edge-funktioner kan du lösa det genom att servera ett cachat skal och injicera personaliserade element vid edge. Eller köra A/B-tester genom att välja variant vid edge istället för med client-side JavaScript, vilket eliminerar layout shifts och flicker.
Geolocation-baserade features
Redirects baserade på land, språkval, prisvisning i lokal valuta, compliance-anpassningar (GDPR-banners bara för EU-trafik). Edge-funktioner har tillgång till geolocation-data utan extra latens, och den här typen av logik är enkel nog att den passar perfekt i edge-miljöns begränsningar.
Middleware i Next.js
Next.js middleware körs på edge per default i Vercel. Det passar bra för:
- Autentiseringskontroller innan sidladdning
- URL-rewriting och redirects
- Feature flags
- Bot-detection
- Header-manipulation
Middleware är ofta det enklaste sättet att börja använda edge computing utan att omstrukturera hela applikationen.
När det inte lönar sig
Edge computing är inte universellt bättre. Det finns tydliga scenarier där det antingen inte ger vinst eller aktivt gör saker mer komplicerade.
Rena statiska sajter
Om din sajt är helt statisk, byggd med en static site generator eller exporterad som statisk HTML, behöver du inte edge-funktioner. Ett vanligt CDN cachar dina filer globalt och serverar dem med låg TTFB. Edge computing löser inte ett problem som inte finns.
Det här gäller överraskande många sajter. En företagssida, en blogg, en dokumentationssajt. Om innehållet inte är dynamiskt per request är static + CDN den snabbaste och billigaste lösningen.
Applikationer med tunga server-beräkningar
Om din server-side rendering kräver komplexa beräkningar, stora databasjoins, eller interaktion med interna system som bara finns i ett datacenter, ger edge-funktioner lite värde. Koden måste ändå prata med backend-tjänster i en specifik region, och edge-miljöns begränsningar (CPU-tid, minne, runtime-APIs) gör det svårare att köra tung logik.
Ett CMS-drivet system där varje sidladdning kräver flera databasfrågor mot en PostgreSQL-instans i Frankfurt tjänar inte mycket på att flytta renderingslogiken till edge. Requesten hamnar ändå i Frankfurt för att hämta data.
Liten, lokal publik
Om 95% av din trafik kommer från Sverige och din server står i Stockholm eller Frankfurt spelar edge computing en marginell roll. Latensen inom Europa är redan låg. Skillnaden mellan 30 ms och 80 ms TTFB är knappt märkbar för användaren. Investeringen i edge-kompatibel arkitektur ger i det fallet dålig avkastning.
Applikationer som kräver full Node.js-kompatibilitet
Om din applikation förlitar sig på Node.js-specifika APIs, native modules, eller npm-paket som inte är edge-kompatibla, innebär en migration till edge att du måste byta ut eller omskriva delar av din stack. Det kan vara värt det i vissa fall, men det är inte en enkel konfigurationsändring.
Kostnaden
En aspekt som sällan nämns i jämförelser är prissättningen. Edge computing är inte gratis, och prismodellen skiljer sig från traditionell hosting.
Cloudflare Workers betald plan kostar 5 USD/månad plus 0,30 USD per miljon requests efter de första 10 miljonerna. KV, R2 och D1 har separata priser. För en liten sajt med låg trafik är det billigt. För en sajt med hög trafik och många KV-reads kan det bli mer än en enkel VPS.
Vercel Edge Functions ingår i Vercels prisplaner. Pro-planen (20 USD/månad) inkluderar en generös mängd edge function-exekveringar, men vid hög trafik kan tilläggskostnader tillkomma.
Deno Deploy har en free tier med 1 miljon requests per månad och en Pro-plan på 20 USD/månad.
Jämför det med en VPS på Hetzner för 4 EUR/månad som ger dig en fullständig Linux-server. Skillnaden är att VPS:en står på ett ställe och edge-funktionerna körs överallt. Men om du inte behöver "överallt" är VPS:en dramatiskt billigare.
Konkreta steg för att komma igång
Om du efter att ha läst det här tror att edge computing kan ge din applikation något, här är ett pragmatiskt tillvägagångssätt.
Steg 1: Mät först
Innan du ändrar något, mät din nuvarande TTFB från olika geografiska platser. Verktyg som WebPageTest (med testplatser i olika regioner), Lighthouse, eller en enkel curl med timing gör jobbet:
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\n" https://din-sajt.se
Kör det från flera platser (eller använd en tjänst som mäter globalt). Om din TTFB redan är under 100 ms för dina målmarknader har du kanske inte ett latensproblem att lösa.
Steg 2: Börja med middleware
Om du kör Next.js på Vercel är middleware det enklaste instegget. Skapa en middleware.ts i roten av ditt projekt. Landet läses med paketet @vercel/functions, eftersom request.geo togs bort i Next.js 15:
import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';
import { geolocation } from '@vercel/functions';
export function middleware(request: NextRequest) {
const country = geolocation(request).country ?? 'SE';
// Redirect till rätt språkversion baserat på land
if (country === 'NO' && !request.nextUrl.pathname.startsWith('/no')) {
return NextResponse.redirect(new URL('/no' + request.nextUrl.pathname, request.url));
}
return NextResponse.next();
}
export const config = {
matcher: ['/((?!api|_next/static|_next/image|favicon.ico).*)'],
};
Det här körs på edge automatiskt och ger dig geolocation-baserad routing utan att du behöver tänka på infrastruktur.
Steg 3: Testa en Cloudflare Worker
Om du vill testa edge computing utanför Next.js-ekosystemet, sätt upp en enkel Cloudflare Worker:
npm create cloudflare@latest my-worker
cd my-worker
Skriv en enkel worker som returnerar data baserat på besökarens plats:
export default {
async fetch(request: Request): Promise<Response> {
const cf = request.cf;
const data = {
country: cf?.country,
city: cf?.city,
colo: cf?.colo, // Vilken edge-nod som hanterar requesten
timestamp: new Date().toISOString(),
};
return new Response(JSON.stringify(data, null, 2), {
headers: { 'Content-Type': 'application/json' },
});
},
};
Deploya med npx wrangler deploy och testa från olika platser. Det ger en konkret känsla för hur edge-exekvering fungerar.
Steg 4: Identifiera vilka routes som passar
Gå igenom dina routes och identifiera vilka som:
- Har hög trafik från geografiskt spridda platser: dessa tjänar mest på edge
- Har enkel logik som inte kräver databasanrop: dessa är enklast att flytta
- Hanterar autentisering eller routing: dessa passar edge-middleware
- Gör tunga databasanrop mot en central databas: dessa tjänar troligtvis inte på edge
Steg 5: Mät igen
Efter att du implementerat edge-funktioner, mät TTFB igen från samma platser. Jämför siffrorna. Om förbättringen är marginell (säg 20 ms för en publik som ändå sitter nära din server) kanske det inte motiverar den ökade komplexiteten. Om förbättringen är 200+ ms för en stor del av din trafik har du en konkret vinst.
Edge som optimering
Edge computing för webben är ett användbart verktyg med ett tydligt användningsområde: att minska latens för geografiskt spridd trafik som kräver dynamisk logik. Det är inte en universell uppgradering som gör alla sajter snabbare.
De plattformar som finns idag, Cloudflare Workers, Vercel Edge Functions och Deno Deploy, har mognat till den punkt där de är pålitliga och relativt enkla att använda. Begränsningarna (ingen full Node.js, exekveringstidsgränser, databasanslutningar) är verkliga men hanterbara om du förstår dem innan du börjar bygga.
Den mest produktiva attityden till edge computing är att behandla det som en optimering, inte en arkitektur. Bygg din applikation med en konventionell stack först. Mät var latensen är ett problem. Flytta sedan specifika delar till edge där det ger mätbar förbättring. Den ordningen sparar dig från att kämpa med edge-begränsningar i situationer där en vanlig server i rätt region hade löst problemet enklare.
Källor
- Cloudflare: Introducing Cloudflare Workers
- Cloudflare Docs: Workers limits
- Cloudflare Docs: Workers pricing
- Cloudflare Changelog: Run Workers for up to 5 minutes of CPU-time
- Vercel Changelog: Edge Middleware and Edge Functions are now powered by Vercel Functions
- Next.js: How to upgrade to version 15