Workers vs. the Cloud: A Fresh Look at Edge Compute Speed
Cloudflare Workers is now four years old. In that time the platform has grown from a compute experiment at the edge to a full-featured development environment with storage, debugging tools, and observability support. But the core promise remains the same: code that runs close to the user is code that feels fast. To see how well that promise holds up today, we re-ran the kind of global, end-to-end benchmark we published three years ago—and the results show a platform that has gotten meaningfully quicker.
Compared to the 2018 numbers, Workers is 30% faster at the P90 mark. Against the incumbent cloud serverless offerings, the gap is even wider: Workers is 210% faster than Lambda@Edge and 298% faster than Lambda in these tests.
How We Test
Benchmarking serverless platforms is not the same as benchmarking CDNs. With a CDN you can measure the delivery of a static asset from locations around the world. With compute, you need every platform to execute the same operation with the same computational complexity. We used Catchpoint, a global monitoring service, to run identical functions from 50 nodes spread across North America, South America, Europe, Asia, and Oceania.
The metric that matters is end-to-end latency. From a user's perspective, it doesn't matter whether a delay comes from DNS resolution, network congestion, or a cold start. All that matters is how long it takes to get a response. That is why we measure from the client's vantage point rather than from inside the cloud provider's network.
The results are consistent across geographies. Whether your users are in North America, Europe, or Asia, Workers delivers the fastest response times—and it does so without any additional configuration. There is no region selection, no load balancing setup, and no tuning required to get optimal performance anywhere in the world.
That advantage holds even when you aren't trying to serve a global audience. In a test run from Washington, DC—as close to AWS's us-east-1 region as we could get—Workers was still 34% faster with zero optimization. The platform's architecture, not its proximity to a specific test node, is what produces these results.
Why the Gap Exists
From the end user's perspective, serverless performance comes down to two factors: how far the code runs from the user, and how long the runtime takes to spin up.
The first factor is pushing many vendors toward the edge. Smaller data centers placed closer to populations reduce the distance a request has to travel. But this strategy collides with the second factor for any platform built on containers. Every time a container is spun up, the entire language runtime must be initialized along with the application code. Smaller edge locations have fewer machines and less memory, which increases the probability that any given request hits a cold start.
This is the fundamental trade-off that container-based serverless platforms cannot escape. They can move compute closer to users by deploying to smaller facilities, but then cold-start frequency rises. Or they can centralize to reduce cold starts, but that puts compute further away from users. As the benchmarks show, Lambda@Edge actually had slower P90 performance than the more centralized Lambda, because the edge locations that power it spin up containers more frequently. The architecture creates a performance ceiling.
Isolates Change the Equation
Workers was built for the edge from the start, not retrofitted into it. Cloudflare's architecture runs each Worker inside a lightweight V8 isolate rather than a containerized process. Isolates spin up in milliseconds, which means there is no cold-start penalty to pay when a request arrives. Cloudflare eliminated that bottleneck entirely last year.
This design also means Workers gets faster automatically as the underlying technology improves. When the V8 engine announced Liftoff, its WebAssembly compiler, every WASM Worker instantly became faster. Cloudflare's network improvements—new data centers, new protocols like HTTP/3—benefit Workers the same way.
The platform also benefits from its own scale. Workers serves millions of requests per second for hundreds of thousands of developers. When the team finds and fixes a performance issue for one customer, the improvement propagates to the entire platform.
Performance Beyond the Request
Latency isn't the only place where speed shows up in the developer experience. Deployments on Workers propagate globally in under a second. The full development loop—from sign-up to debugging—has been the focus of ongoing work to remove friction at every stage.
The point of serverless is to let developers concentrate on building features rather than managing infrastructure. Choosing a platform that delivers strong performance out of the box is part of that equation. The best way to validate these numbers is to try the platform yourself: you can deploy your first Worker in a few minutes and see how it performs from wherever your users are.
