Edge functions are short-lived pieces of code that a platform runs in a globally distributed network of edge locations, close to the user who sent the request, instead of in one central cloud region. They are a form of serverless computing: the developer deploys a function, and the provider handles placement, scaling and routing across hundreds of points of presence.
Typical tasks are request routing, authentication checks, personalization, A/B testing, header rewriting and lightweight API responses. Because the code runs a short network distance from the user, edge functions can cut round-trip latency substantially, but they trade that advantage for tighter limits on execution time, memory and available APIs.
How edge functions execute requests
An edge function is triggered when an HTTP request reaches the nearest edge location, usually through the same anycast network that a content delivery network uses. The platform loads the function, passes it the request object and returns whatever response the function produces, or forwards a modified request to the origin server.
Many platforms run edge code in V8 isolates rather than containers or virtual machines. An isolate is a lightweight sandbox inside a shared JavaScript engine process, so starting one takes a few milliseconds or less, which largely removes the cold start penalty familiar from region-based functions. Other platforms use WebAssembly runtimes or slimmed-down container models with similar goals.
The table below outlines the main execution models used for code at the edge.
| Model | Startup time | Language support | Isolation strength |
|---|---|---|---|
| V8 isolates | Very fast, often under 5 ms | JavaScript, TypeScript, WebAssembly | Process-shared sandbox |
| WebAssembly runtime | Very fast | Languages compiled to Wasm | Memory-safe sandbox |
| Micro virtual machines | Fast, tens of milliseconds | Broad | Strong hardware isolation |
| Containers at edge sites | Slower | Any | Strong, higher overhead |
Typical limits and runtime parameters
Edge functions run on shared infrastructure in many locations, so providers impose strict resource limits. Exact values differ by platform and plan, but the order of magnitude is consistent and shapes what the code can reasonably do.
| Parameter | Typical range | Practical consequence |
|---|---|---|
| CPU time per request | Milliseconds to tens of seconds | No heavy computation |
| Memory | About 128 MB per isolate or function | Small data sets only |
| Bundle size | Around 1 to 10 MB compressed | Few large dependencies |
| Runtime APIs | Web standard Fetch, Streams, Crypto | Many Node.js modules unavailable |
| Persistent state | None inside the function | External key-value or database needed |
A crucial distinction is between CPU time and wall-clock time. Many platforms count only active CPU work, so waiting for a network response does not consume the budget, but long chains of sequential calls still increase the latency the user experiences.
Edge functions compared with regional serverless functions
Edge functions and regional functions such as AWS Lambda or Azure Functions share the serverless billing and scaling model, but they optimize for different things. Edge functions optimize for proximity to the user; regional functions optimize for proximity to data and for richer runtimes.
| Aspect | Edge functions | Regional functions |
|---|---|---|
| Location | Hundreds of edge sites | One or a few cloud regions |
| Latency to user | Very low | Depends on distance to region |
| Cold start | Minimal with isolates | Noticeable without provisioned concurrency |
| Execution limits | Tight CPU and memory | Minutes of runtime, more memory |
| Access to databases | Often far away | Close to regional data |
| Best fit | Routing, auth, personalization | Business logic, batch, heavy APIs |
Cloudflare Workers is a well-known edge platform; content delivery networks and front-end hosting platforms offer comparable products. Containers on Google Cloud Run or AWS Fargate sit at the other end of the spectrum, with full runtimes but regional placement.
When to use edge functions
Edge functions fit work that is small, latency-sensitive and close to the HTTP layer. The decision table below matches typical needs with the place where the logic belongs.
| Situation | Recommended placement | Reason |
|---|---|---|
| Redirects and geo routing | Edge function | Decided from request data alone |
| Token validation | Edge function | Rejects bad requests before origin |
| Personalizing cached pages | Edge function | Keeps cache benefits per user |
| Complex database transactions | Regional function or server | Data locality and long runtimes |
| Image or video processing | Regional compute | Exceeds edge CPU limits |
Combining both is common: the edge function filters, routes and enriches requests, while a regional backend performs the heavy work and stores data.
Limitations and common mistakes
The most frequent mistake is placing code at the edge that calls a distant database several times per request. Each call crosses the network back to a central region, so the total response can become slower than running the whole function next to the database.
- Data gravity: state remains centralized unless the data layer is also distributed or replicated.
- Runtime incompatibility: libraries that depend on file systems or native modules may not run.
- Observability gaps: logs and traces are spread across many locations and need central collection.
- Consistency trade-offs: edge key-value stores are often eventually consistent, so recent writes may not be visible everywhere at once.
- Vendor lock-in: platform-specific APIs make migration harder; web standard APIs reduce that risk.
Stripped to the essentials
Edge functions are small programs that run in many locations around the world at once. Each visitor is served by a computer nearby instead of one far away.
Imagine a company that has a small reception desk in every city instead of one head office. The desks cannot do every job. They can still answer quick questions, check visitor badges and point people to the right department immediately. The key takeaway is that edge functions make quick decisions fast, while heavy work still happens in a central place.
Where it is applied
A news website serves readers on several continents from a cached front page, but it needs to show a regional banner, enforce a paywall for subscribers and run an experiment with two headline layouts. Doing this on the origin servers in one region would bypass the cache and add hundreds of milliseconds for distant readers.
The team deploys an edge function that reads the visitor’s country from the request, validates the subscription token signature locally, assigns each reader to an experiment group with a cookie and rewrites the cached page accordingly. Only invalid or expired tokens are sent to the central account service. The result is that personalized pages are delivered from nearby edge locations with response times close to those of plain cached content, while origin traffic drops significantly.