When to Use Edge Computing for Your Web App (And When to Stay Server-Side)

Edge computing has been the buzzword of choice for cloud vendors for the last three years. Cloudflare Workers, Vercel Edge Functions, Deno Deploy, AWS Lambda@Edge, Fastly Compute, every major platform has a flavor. The pitch is the same everywhere. Your code runs close to your users, latency drops, conversions go up, life is good.

The pitch is partially true. The trouble is that "partially" is doing a lot of work in that sentence. Putting the wrong workload on the edge will cost you more money, slow your app down in measurable ways, and create debugging headaches your team is not equipped for.

Here is the practical decision framework we use with clients before we move anything to the edge.

1. What "edge" actually means in 2026

Strip the marketing and you get this. Your code is deployed to a network of small data centers (also called points of presence) scattered across the globe, typically 200 to 350 of them depending on the provider. When a user makes a request, it routes to the nearest one and runs there, instead of traveling to your single origin region.

For a user in Sao Paulo hitting an app hosted in us-east-1 in Virginia, the round-trip just for the network leg is around 130ms before your server does anything. If the same code runs in a Sao Paulo edge location, that drops to under 10ms. That is the entire pitch.

The catch is that edge runtimes are stripped down. Smaller memory limits (often 128MB), shorter execution windows (50ms of CPU on Cloudflare Workers, longer on Vercel), restricted APIs, and limited or no access to your primary database. You are trading raw capability for global proximity.

2. Where edge genuinely wins

Edge shines for work that is small, fast, stateless, and benefits from being close to the user. Six categories where the math is almost always favorable:

Auth and session checks. Validating a JWT, checking a session cookie against a KV store, blocking unauthenticated requests before they ever reach your origin. Saves origin compute and shaves real latency off every authenticated page.

A/B test routing. Deciding which variant a user sees based on a cookie or hash, then rewriting the request. The decision needs to happen before HTML is generated. Edge is the only place this can live without hurting LCP.

Image optimization. Resizing, reformatting, compressing on the fly. Cloudflare Image Resizing and Vercel's Image Optimization both run at the edge. Caches are populated locally so the second user in Sydney does not pay the cost again.

Geolocation-based content. Showing prices in the right currency, defaulting to the right language, swapping the regional disclaimer. The edge runtime hands you the user's country in a header. No IP lookup, no third-party API call.

Redirects and URL rewrites. Marketing campaigns, shortened URLs, legacy slug mapping. A redirect at the edge returns in 10 to 30ms globally. The same logic at origin can take 200ms before the browser even starts the next request.

Rate limiting and bot mitigation. Stopping abusive traffic before it touches your application. Every blocked request that does not reach origin is money saved and load avoided.

Notice the pattern. None of these need a database write. None of them need to think for more than a few milliseconds. All of them sit on the request path of every user.

3. Where origin still wins

The cases where edge is the wrong answer are equally clear once you name them.

Anything that needs your primary database. Most apps run Postgres or MySQL in a single region. A Cloudflare Worker in Singapore querying a Postgres in Virginia just moved your latency problem from the user to the database call. You did not save anything, you spread the same 130ms across a different leg of the trip. Until your data layer is genuinely global (Planetscale, Neon with regional read replicas, Cloudflare D1, FaunaDB), heavy database work belongs near the database.

Complex business logic. Edge runtimes have CPU and memory caps that make heavy work either expensive or impossible. Generating a PDF, running a complex pricing calculation across many SKUs, processing a 10MB CSV upload. These belong on a regional server with breathing room.

Long-running tasks. Anything past a few seconds. Background jobs, video transcoding, AI inference on large models, batch processing. Edge is the wrong shape entirely. Use a queue and a worker pool at origin.

Code with large dependencies. Edge bundles often have a 1MB or 10MB cap depending on the platform. If your function pulls in a big SDK, a machine learning library, or a PDF rendering engine, you will hit the wall fast. Origin runtimes do not care.

Anything stateful. Session state that needs to be consistent across regions, financial transactions, anything where two users can race for the same resource. The edge can read shared state quickly via KV stores, but writes are eventually consistent in most providers. That matters when correctness is non-negotiable.

4. The cost reality nobody puts on the slide

Edge invocations are dramatically more expensive per request than origin compute. Rough orders of magnitude, current pricing as of 2026:

• Cloudflare Workers: about $0.30 per million requests on the standard plan.
• Vercel Edge Functions: about $0.65 per million invocations after the included tier.
• An EC2 t4g.small running 24/7 handling roughly 30 million requests a month: about $13 fixed, or $0.0004 per million requests.

That is a 10 to 50x multiplier per invocation, depending on workload and how full the origin server is. The math only works in your favor when one of two things is true. Either the latency win translates to real revenue (an ecommerce checkout, a paid signup flow, a high-conversion landing page), or the work is genuinely something you cannot do at origin without a worse user experience.

If you are running edge functions for an internal admin tool with twenty users a day, you are setting money on fire for no measurable benefit.

5. The latency-to-revenue math

The reason serious teams still adopt the edge despite the per-request cost is that latency moves money at scale. The numbers are real and well documented.

A global apparel retailer migrated their product page rendering and image optimization to Cloudflare Workers, cutting Largest Contentful Paint by roughly 400ms for international visitors (mostly Asia and Europe hitting a US origin). Conversion rate on those geographies lifted by about 6% in the following quarter. On an eight-figure annual revenue base, that pays for the edge bill many times over.

The Aberdeen Group, Akamai, and Google have all published variants of the same finding. A 100ms improvement in load time correlates with a 1 to 3% conversion lift on commerce sites. The relationship is not linear forever (you cannot get to 0ms and infinite conversions), but the slope is real in the 1 to 4 second range where most real apps live.

The point is not that edge is always worth it. The point is that you should do the math. If your audience is regional and your origin is already close to them, the edge buys you very little. If your audience is global and a meaningful slice of revenue comes from users 5000 miles from your origin, the edge probably pays for itself the first month.

6. The hybrid pattern that actually works

For most production apps, the right architecture is not "all edge" or "all origin." It is a clean split where each layer does what it is best at.

Edge layer (request routing and lightweight logic):

• TLS termination and HTTP/3 negotiation.
• Auth token validation against a KV cache.
• Geolocation and language detection.
• A/B test variant assignment.
• Cache lookups for static and semi-static responses.
• Image optimization and asset transforms.
• Rate limiting and bot blocking.
• URL rewrites and redirects.

Origin layer (the actual work):

• Database reads and writes.
• Business logic.
• Background jobs and queues.
• Anything stateful or transactional.
• Heavy computation, AI inference, file processing.

The contract between the two is simple. The edge layer either responds itself (cache hit, redirect, rejected request) or it forwards a clean, validated request to origin with extra headers (user country, A/B variant, auth claims). Origin does not have to repeat any of that work. This is how Vercel's middleware, Cloudflare's Workers in front of an origin, and Fastly's compute layer in front of any backend are designed to be used.

7. A practical decision checklist

Before you move a workload to the edge, run it through these five questions. If you answer no to any of the first three, stay at origin.

1. Is this work small and fast? If the function needs more than 50ms of CPU or pulls in heavy dependencies, no.
2. Is this work stateless or backed by a globally replicated store? If it needs your single-region Postgres, no.
3. Does proximity to the user actually help here? If the user is going to wait on origin afterwards anyway, the edge hop is wasted.
4. Will the latency win translate to revenue or experience? Quantify it before you commit. A 30ms saving on a back-office tool is not a real win.
5. Can your team operate it? Edge debugging is harder. Logs are scattered across regions, local development is platform-specific, and observability tooling is younger. Make sure you have the muscle.

If you say yes to all five, move it. If you say yes to four, pilot it on one route and measure. If you say yes to three or fewer, leave it on origin and revisit in six months.

The honest summary

Edge computing is a real performance tool, not a religion. Used in the right places (auth, routing, caching, image work, geolocation), it makes global apps feel local and pays for itself in conversion lift. Used in the wrong places (database-heavy logic, stateful work, anything large), it adds complexity, cost, and debugging pain for no measurable user benefit.

Architect for both. Treat the edge as your front door and your origin as your kitchen. The teams who think clearly about this split (and who measure latency and revenue together rather than chasing benchmarks) build the apps that feel fast everywhere without a runaway cloud bill. That is the same principle we apply when we plan web development projects with global audiences from day one.