The Edge Computing Opportunity Isn’t About Latency

Cloudflare Workers has grown into one of the largest edge computing platforms since its announcement nearly three years ago, with hundreds of thousands of developers writing tens of millions of lines of code. Last quarter alone, 20,000 developers deployed their first Workers application, and more than 10% of all requests flowing through Cloudflare’s network now use the platform. Among the company’s largest customers, roughly 20% have adopted Workers.

But the company’s own analysis of how developers actually use the platform suggests the industry has been chasing the wrong metric. The assumption at launch was that speed would be the killer feature; code running across a distributed network closer to users would inherently outperform centralized serverless platforms. In practice, that has not been what drives adoption.

Legacy platforms that emphasized latency alone have already failed once. Akamai launched a Java- and .NET-based edge computing platform in 2002, only to shut it down in 2009 because a bit less network latency did not justify the added cost and complexity for enough customers. Cloudflare’s conclusion is that a similar mistake is being repeated today.

What Developers Actually Prioritize

Speed is best thought of as the top of a hierarchy rather than the foundation. The proposed ordering, from least to most important, is: Speed < Consistency < Cost < Ease of Use < Compliance.

Speed remains attractive, and Cloudflare’s network spans more than 100 countries, putting compute within milliseconds of users. An application that must pick an availability zone will always be at a performance disadvantage to one that runs across a distributed network. But relatively few applications are truly sensitive to latency differences of a few hundred milliseconds. Credit card processing, ad delivery, gaming, and voice assistants benefit measurably; IoT and driverless cars are often named as edge computing use cases, but those discussions tend to be speculative.

Premature optimization is rarely a compelling reason to switch platforms. Several factors weigh more heavily in practice.

Consistency Beats Speed

Cold starts — the time it takes for code to execute the first time on a particular server — are a problem for all serverless platforms. They introduce unpredictability, and user experience suffers more from inconsistency than from raw latency. Distributed platforms can make this worse: spreading workloads across more locations means code is less likely to be warm on any given server.

Workarounds like idle requests to keep code hot are wasteful, and cloud providers will bill for those throw-away requests. Cloudflare’s approach has been to keep cold starts under 5 milliseconds, compared with AWS Lambda, where cold starts have been observed to take as long as 5 seconds. The company now says Workers supports zero-nanosecond cold starts, eliminating this source of variability entirely.

Pricing Model and Architecture

Edge platforms have typically charged a premium for lower latency; AWS’s Lambda@Edge has cost approximately three times as much per request as standard Lambda. That pricing logic keeps edge computing a niche product for latency-sensitive workloads only.

There is no inherent reason edge computing must cost more. Well-peered networks can deliver bandwidth locally at lower cost than backhauling traffic around the world, with additional savings on power and colocation. But the larger cost advantage comes from the underlying execution model.

The progression of compute efficiency has moved from dedicated servers to VMs to containers, each reducing overhead per application. Cloudflare’s answer to what comes after containers is isolates — the sandboxing technology browsers use. Because isolates are far lighter weight than containers or VMs, compute overhead is much lower, and the savings can be passed along.

The original Workers pricing charged only per request, which required caps on CPU, memory, and application size. A new pricing option will follow the standard serverless model of charging for requests, CPU time, and bandwidth, but with the intent of undercutting Lambda pricing significantly.

Ease of Use and Developer Experience

Developers tend to stay with familiar tools. Cloudflare Workers already supports JavaScript, C, C++, Rust, Go, and COBOL, and is adding Python, Scala, and Kotlin. Debugging is a known pain point for serverless platforms generally; deployment to Lambda@Edge has at times taken as long as 5 minutes. Workers deployments propagate across the network in less than 15 seconds.

A usability principle Cloudflare adopted internally is that engineers must build new features on Workers when possible, and any APIs or tools built internally must be made available to third-party developers. The Wrangler command-line tool for provisioning and debugging has matured from this feedback loop.

Compliance as the Real Driver

For developers at banks, insurers, healthcare companies, and other organizations handling sensitive data, regulatory compliance often determines which platforms are even eligible for adoption. GDPR, PCI DSS, FedRAMP, ISO27001, and SOC 1/2/3 certifications are baseline requirements. But a new wave of regulation is creating a larger challenge.

Countries including the EU, India, Brazil, and China are pursuing or imposing data sovereignty rules that require their citizens’ data to be stored and processed within national borders. Regardless of whether such policies are sound, the momentum behind them is substantial. For centralized cloud platforms, this fragmentation threatens the economies of scale that made serverless attractive, and coordinating between platforms across jurisdictions becomes a network of compliance obligations.

This is where the distributed architecture becomes strategically significant. A single platform running code locally in more than 100 countries is positioned to satisfy data-sovereignty requirements while preserving the scaling efficiency of serverless. The coming promise of serverless was to let developers ignore where code runs; the next era may require knowing exactly where it runs and proving that location to regulators. The platforms that make that easy — not merely the fastest ones — will win the next wave of adoption.