Edgecomputingförvanligasajter:VadCloudflareWorkersochVercelEdgefaktisktgerdig

I september 2017 lanserade Cloudflare Workers som en public beta. Idén var att låta utvecklare köra JavaScript-kod på Cloudflares nätverksinfrastruktur, utspritt över mer än 300 datacenter runt världen. 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 faktiskt 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 först 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 upp till 30 sekunder CPU-tid. Minnessgrä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 bygger under huven på Cloudflare Workers. Det betyder att du får samma V8 isolate-modell och liknande prestanda. Skillnaden ligger i integrationen: Edge Functions är djupt integrerade med Next.js och Vercels deployment-pipeline.

I praktiken aktiverar du en Edge Function genom att lägga till export const runtime = 'edge' i en Next.js route handler eller middleware. Koden körs sedan i ungefär 20 compute-regioner globalt (färre än Cloudflares 300+, men tillräckligt för bra global täckning).

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 har också noll cold starts i deras marknadsföring, 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 Stockholm–Singapore via 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.

Konkreta siffror från verkliga tester visar ungefär:

• 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 som ingen pratar om på konferenser

Edge-miljöer är inte miniservrar. De är avsiktligt begränsade, och de begränsningarna påverkar vad du faktiskt 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åtkomst
• child_process: kan inte köra externa processer
• net / dgram: inga raw sockets
• crypto i 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, vilket är mer rimligt men 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.

Kallade starts, eller snarare, inte

V8 isolates har i praktiken inga cold starts i den traditionella bemärkelsen. Men det finns en annan form av delay: om din Worker inte har körts på en specifik edge-nod på ett tag kan den behöva laddas dit, vilket kan ge 5-20 ms extra. Det är inte en cold start i container-bemärkelsen (hundratals ms till sekunder) men det är inte heller noll.

Vilka sajter som faktiskt 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, bygd 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:

import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';

export function middleware(request: NextRequest) {
  const country = request.geo?.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 rätt kandiderande routes

Gå igenom dina routes och identifiera vilka som:

1. Har hög trafik från geografiskt spridda platser: dessa tjänar mest på edge
2. Har enkel logik som inte kräver databasanrop: dessa är enklast att flytta
3. Hanterar autentisering eller routing: dessa passar edge-middleware
4. 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.

Är edge computing värt det?

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 faktiskt ä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.