What is Edge Function?
Definition
An edge function is a small, short-lived piece of serverless code that runs on a CDN's globally distributed servers, in the location closest to the user. It handles requests before they reach the origin server, for tasks such as redirects, header changes, access checks or light personalisation, with very low latency. The broader idea of moving computation towards users is called edge computing.
Also known as: edge functions, edge computing, edge worker, edge runtime
Moving compute towards the user
In a traditional setup, a request from a visitor in Istanbul travels to wherever the server lives and back. A CDN shortened that trip for static files long ago, serving images, CSS and JavaScript from a nearby data centre. Edge computing applies the same idea to code: if deciding on a redirect or adding a header doesn't require crossing an ocean, the CDN's point of presence can do it.
Edge functions are how platforms expose that capability to developers. Cloudflare Workers, Vercel and Netlify deploy your function to many locations and run each request at the closest one.
CDN vs regional serverless vs edge
| CDN cache | Regional serverless | Edge function | |
|---|---|---|---|
| What runs | No code; a stored response is served | A full runtime such as Node.js | A restricted, web-standards runtime |
| Where | Hundreds of locations | One or a few chosen regions | Hundreds of locations |
| Dynamic? | No | Yes | Yes, for short tasks |
| Typical job | Static assets | Business logic, database access | Routing, headers, access checks |
In that sense an edge function is a particular flavour of serverless: someone else still runs the servers, but the code executes in a different place and under tighter constraints.
Isolates and their limits
Many edge platforms avoid starting a container or virtual machine per function and use V8 isolates instead. Cloudflare's documentation says an isolate starts roughly a hundred times faster than a Node process in a container or VM and uses an order of magnitude less memory, which largely removes the cold-start problem of classic serverless.
The trade-off is a narrower environment. On Cloudflare Workers, each isolate can use up to 128 MB of memory, and CPU time per request is capped at 10 ms on the free plan and 30 seconds by default (up to 5 minutes) on paid plans. The runtime provides web-standard APIs such as fetch, Request and Response; there is no general filesystem and only part of the Node.js API surface. Libraries built on native Node add-ons will not run there.
Answering before the origin is involved
This Cloudflare Worker permanently redirects old blog URLs and adds a security header to everything else:
export default {
async fetch(request) {
const url = new URL(request.url);
if (url.pathname.startsWith("/old-blog/")) {
url.pathname = url.pathname.replace("/old-blog/", "/blog/");
return Response.redirect(url.toString(), 301);
}
const response = await fetch(request); // pass through to the origin
const copy = new Response(response.body, response);
copy.headers.set("X-Content-Type-Options", "nosniff");
return copy;
},
};The redirect is answered at the nearest location and the origin never sees the request. Assigning A/B test buckets, routing visitors to a language version, validating a simple token and filtering obvious bots are similar edge-friendly jobs.
The data-distance trap
The function may sit next to the user, but the database usually lives in one region. An edge function that makes three queries per request sends each one on the long trip, quickly wiping out any gain in latency. Data-heavy work belongs close to the data; the edge suits tasks that need no data or can be served from a cache. Platform guidance has shifted in this direction: Vercel's documentation now recommends migrating from its edge runtime to Node.js for performance and reliability, and in Next.js 16 the proxy file that replaced middleware runs on Node.js by default. Measure the benefit with real TTFB data rather than assuming it.