Because distance is physics. If your server sits in Virginia and your customer is in Sydney, every request makes a round trip of thousands of kilometres before a single byte comes back. Edge computing shortens that trip by running your code in a location near the user instead of one fixed region.
We see this most on sites that look fast in a local test and feel slow in the real world. The team is in London, the server is in London, and the report from the Singapore office says the site takes forever. Nobody is wrong. They are measuring different distances.
Edge computing is a real fix for a real problem. It is also one of the most oversold ideas in web infrastructure, and the market has cooled on it noticeably in 2026. Here is what it does, what it costs, and how to tell whether it applies to you.
Edge computing means running code in many locations close to your users rather than in one central data centre. Instead of every request travelling to a single origin server, requests are handled at whichever location is nearest. The result is less network distance, and therefore less waiting, before work begins.
Cloudflare describes Workers, its edge platform, as a serverless platform for building, deploying, and scaling apps across Cloudflare global network with a single command. Vercel takes the same shape with its Edge runtime, whose documentation states that by default those functions execute in the region closest to the incoming request.
The word edge simply means the outer boundary of a network, near the user, as opposed to the core where your origin lives. There is nothing mystical about it. It is the same code you already write, running somewhere geographically closer.
A CDN copies files to locations near your users. Edge computing runs logic at those locations. A CDN can hand a visitor in Tokyo a cached image instantly, but it cannot decide anything. Edge computing can check a cookie, rewrite a URL, or personalise a response before the page is served.
This is why the two get confused. They use the same global footprint, and the newer edge platforms grew out of CDN companies. The difference is whether the network is serving something it already has or computing something new.
For most business websites, the CDN half is doing almost all of the useful work already. If you are not sure what your CDN is currently handling, that is worth understanding first, and we covered it in our guide to what a CDN is and whether your website needs one. A lot of teams reach for the edge to solve a problem their CDN would solve for free.
Not in a normal server process. Edge platforms use lightweight JavaScript isolates rather than containers or virtual machines, which is what makes it practical to keep thousands of applications warm across hundreds of locations at once. Vercel documentation states its Edge runtime is built on the V8 engine and runs in isolated execution environments that do not require a container or virtual machine.
Cloudflare explains the same architecture in its Workers documentation. It states that unlike other serverless providers which use containerized processes each running an instance of a language runtime, Workers pays the overhead of a JavaScript runtime once, and can run essentially limitless scripts with almost no individual overhead.
The performance claim follows from that design. Cloudflare states that any given isolate can start around a hundred times faster than a Node process on a container or virtual machine, and that isolates consume an order of magnitude less memory on startup. That is the real advantage of the model, and it is a genuine engineering achievement.
The trade is that an isolate is not a full server. You get a curated set of web APIs, not the whole runtime, which brings us to the part teams underestimate.
Quite a lot, and this is where projects go wrong. Vercel documentation for the Edge runtime states plainly that you cannot read or write to the filesystem, that calling require directly is not allowed, and that dynamic code execution using eval or new Function is disabled for security reasons.
Library compatibility is the practical killer. Vercel notes that most libraries which depend on Node.js APIs cannot be used in edge middleware, and that node modules can only be used if they implement ES modules and avoid native Node APIs. Teams discover this halfway through a build, when the database client or the PDF generator refuses to run.
There are hard ceilings too. Vercel documents that an Edge runtime function must begin sending a response within 25 seconds, though it may continue streaming for up to 300 seconds. It also documents code size limits after gzip compression of 1 MB on Hobby, 2 MB on Pro, and 4 MB on Enterprise plans. Those limits are generous for routing logic and tight for anything resembling an application.
The enthusiasm has clearly cooled, and the evidence is on the vendors own documentation. Vercel Edge runtime page, last updated on 3 August 2026, opens with a recommendation to migrate from edge to Node.js for improved performance and reliability, noting that both runtimes now run on its Fluid compute model.
The same page states that starting in Next.js 16.3, setting the runtime to edge is no longer supported, and that routes and pages run on Node.js. That is about as direct a signal as a platform gives. The special edge tier is being folded back into a general compute model rather than promoted as the default.
We read that as a correction rather than a failure. The original pitch, which was that everything should run at the edge, was always too broad. The constraints of a restricted runtime were a real cost, and for most workloads the latency saving did not pay for them. Meanwhile the underlying idea of running compute close to users has not gone anywhere. Cloudflare Workers is still built on it, and it still works.
The lesson we take into client work is to be suspicious of any infrastructure choice that requires the whole application to adopt it. The edge is excellent for a narrow band of work. It was never going to be the place all code lives.
It reduces the time before your server starts responding, which shows up as better Time to First Byte. Whether visitors feel it depends on where your data lives. Moving your code to Sydney while your database stays in Virginia usually makes things worse, because now the code makes the long trip instead of the request.
That is the trap nobody warns you about. The edge is fast when the work is self contained. The moment your edge function needs to query a central database, you have added a hop rather than removed one. Vercel acknowledges this indirectly by documenting a regions option so you can pin functions near a data source instead of near the user.
TTFB is the metric to watch here, because it is the one that actually moves. If you want to understand what a good number looks like and what drives it, we broke it down in our article on what Time to First Byte is and how to improve it. Fixing TTFB with the edge only makes sense once you know TTFB is your problem.
Three cases in our experience. When you need to make a routing or access decision before the page is served, such as redirects, geographic routing, or A/B assignment. When you serve a genuinely global audience with users far from your origin. And when you need to personalise a cached page without giving up caching.
That third case is the strongest and the least discussed. Normally personalisation kills caching, because every visitor needs a different page. Edge logic lets you serve one cached page and adjust small parts of it near the user, which keeps the speed of static delivery with some of the flexibility of dynamic rendering.
Everything else on a typical marketing site is better served by being static. A prerendered page delivered from a CDN is faster than any compute, at the edge or otherwise, because no code runs at all. We laid out the decision in our piece on whether your website should be static or server rendered, and the answer for most businesses is still static.
More than the marketing suggests. You get a second runtime with different rules, a debugging experience that no longer matches your local machine, and a class of bug that only appears in one region. For a small team, that overhead is real and permanent.
Vendor coupling is the other cost. Edge platforms differ in their APIs, their limits, and their storage options, so code written for one does not simply move to another. Standards work has narrowed the gap, but not closed it. You are choosing a platform, not just a location.
There is also an operational cost people forget. Vercel documents that in the event of regional downtime, traffic reroutes to the next closest region. That is good engineering, and it also means the answer to why was that request slow can now be a region you were not thinking about. Distributed systems are harder to reason about. That is the deal.
For most business websites, no. Prerender your pages, put them behind a CDN, and keep your origin simple. Reach for edge compute only when you have a specific job that must happen before the response, or a genuinely global audience that a static cache cannot serve well. Adopt it for a reason, not as a default.
If you do have that reason, adopt it narrowly. Put the routing logic or the personalisation at the edge and leave the rest of your application where it is. The teams we see succeed with this treat it as one tool in the stack. The teams that struggle rebuilt everything around it and inherited every constraint.
If you are not sure which camp your project falls into, we are happy to look at it with you. Tell us where your users are and where your server is over at phoenix.studio, and we will give you a straight answer. Quite often the fix is a caching header, not a new platform.
Tell us where you want to go. We'll tell you how we'd get you there.