Edge computing sounds like infrastructure concern, far removed from the daily work of a web developer. But the landscape shifted. Cloudflare Workers, Deno Deploy, Vercel Edge Functions, and Netlify Edge Functions made it possible to run server-side code at the network edge with almost no configuration.
In May we ran a series of experiments to find out where edge runtimes genuinely help — and where they add complexity for no measurable gain.
What the edge actually means
Traditional server-side code runs in one or a few data centers. When a user in Tokyo requests a page rendered in Frankfurt, the round trip adds latency. Edge runtimes distribute your code to dozens or hundreds of locations worldwide. The code runs in whichever location is closest to the user.
The promise: lower latency for server-rendered content. The catch: edge runtimes have constraints.
Where edge runtimes shine
Personalized static pages. A marketing site that is ninety percent static but needs to show locale-specific pricing or a logged-in user’s name in the header. At the edge, you can modify a cached HTML response — injecting dynamic content without making the entire page dynamic.
A/B testing without client-side flicker. Traditional A/B testing injects a script that modifies the DOM after load, causing a visible flash. Edge middleware can rewrite the response before it reaches the browser, serving the correct variant with no flicker.
Geolocation-based routing. Redirecting users to region-specific content based on their location. This is trivial at the edge and eliminates an extra round trip to an origin server.
Authentication checks. Validating a session token and redirecting unauthenticated users before the request reaches your application server. This offloads work from your origin and reduces its attack surface.
Where edge runtimes don’t help
Database-heavy operations. If your edge function needs to query a database in a single region, you gain nothing. The function runs close to the user, but the database query still travels to the origin. You need a globally distributed database — or aggressive caching — to see benefits.
Complex computations. Edge runtimes typically have strict CPU time limits (often 10–50 milliseconds). Heavy data processing, image manipulation, or machine learning inference should stay on traditional servers or dedicated compute services.
Anything requiring Node.js-specific APIs. Edge runtimes use a Web Standards-based API surface. If your code depends on fs, child_process, or Node-specific modules, it will not run at the edge without significant refactoring.
Our experiment results
We moved three workloads to the edge:
- Locale detection and redirect — Time to first byte dropped from 380ms to 45ms for international users. Clear win.
- Session validation middleware — Reduced origin server load by forty percent. Minor latency improvement but significant cost reduction.
- Server-rendered product pages with database queries — No improvement. The database was in a single region, so the edge function waited for the same round trip the origin server would have handled.
A practical starting point
If you deploy to Netlify, Vercel, or Cloudflare, you already have edge runtime access. Start with middleware — the lightest possible edge workload. Move authentication checks, redirects, and header modifications to the edge. Measure the impact. Then decide whether heavier workloads justify the constraints.
The edge is not a replacement for your server. It is a layer in front of it — one that, used selectively, can meaningfully improve the experience for users who are far from your origin.
