Measuring a faster path to the edge
When we first published our global network benchmark in September 2021, we compared ourselves against other providers across 1,000 networks worldwide, measuring TCP connection time, time to first byte (TTFB), and time to last byte. At that point, Cloudflare came out fastest in 49% of those networks. Since then, we've set a goal to raise that figure by at least 10% during each Innovation Week, a target we met during Security Week in March 2022. Now, for Platform Week, we're expanding the measurement scope while also digging deeper into how our Workers compute platform stacks up against Fastly's Compute@Edge.
The headline numbers: using the original set of 1,000 networks, Cloudflare is now the fastest provider in 69% of them. Expanding the pool to the 3,000 most-reported networks — a change we're making to better represent real-world connectivity — we lead in 42%. The smaller, long-tail networks in that expanded set are where we expect to make the most gains next.
Reworking the benchmark
After nine months of running the same methodology, we've revised it in several ways. First, we're widening the measured network pool from 1,000 to 3,000 networks based on IPv4 address space, which gives a more granular picture of performance beyond the largest ISPs. Going forward, we'll report results as percentages of networks where we rank #1, since the denominator will keep shifting as we expand coverage.
We also cleaned up our Terms of Service by removing a "no benchmarking" clause that had outlived its purpose. Independent validation of our claims is important, and we welcome well-run tests that push us to improve.
From synthetic probes to real user data
For the Workers vs. Compute@Edge comparison, we used Catchpoint, a synthetic monitoring platform with roughly 2,000 endpoints embedded in ISP networks worldwide. These backbone nodes are connected directly to ISP routers, giving a repeatable approximation of user traffic — though they don't fully replicate home connections, where bandwidth is shared across applications. We selected 300 of these nodes, filtering out cloud providers and metro areas with multiple transit paths to reduce duplicate routes.
We cross-checked those synthetic results against our own real-user dataset. That data comes from error pages served to users on free websites; the page triggers background test calls that report performance metrics back to us. Those calls run independently of the error page, so Cloudflare gets no head start. Both Cloudflare and Fastly were tested using paid accounts.
Looking at wait time
This round, we added Wait time alongside TTFB. Wait time is the period after the connection is established during which the client waits for the first byte — effectively covering server processing plus network transmission of the response. It's a cleaner signal for compute performance because it excludes DNS resolution, connection setup, and cache effects. Our measurements showed zero time spent handing the request off to the server socket, so Wait time accurately reflects on-box processing plus wire time.
TTFB alone can be misleading for serverless workloads because it bundles in connection time, DNS behavior, and cache performance — factors unrelated to how fast code executes. We're reporting both TTFB and Wait time so the picture covers both raw compute speed and end-to-end user experience.
Network performance: where we stand
At Security Week in March 2022, we shared p95 TCP connection time results across the top 1,000 networks. That snapshot showed Cloudflare ahead in more networks than any competitor. The chart from that period is below.

Now, with the expanded 3,000-network view at Platform Week, the distribution shifts as smaller networks enter the pool.

Country-level results tell a similar story. Using the top 1,000 networks, the world map from Full Stack Week shows Cloudflare leading across most regions. Expanding to the top 3,000 networks, we gained #1 status in additional countries in Africa and Europe, including some that previously lacked enough samples to credit any provider.


Workers vs. Compute@Edge
For the compute comparison, we ran three workloads on both platforms: a simple JavaScript function, a complex JavaScript function, and a complex Rust function. The goal was straightforward — measure how each platform handles compute tasks end to end.
async function getErrorResponse(event, message, status) {
return new Response(message, {status: status, headers: {'Content-Type': 'text/plain'}});
}
function testHardBusyLoop() {
let value = 0;
let offset = Date.now();
for (let n = 0; n < 15000; n++) {
value += Math.floor(Math.abs(Math.sin(offset + n)) * 10);
}
return value;
}
fn test_hard_busy_loop() -> i32 {
let mut value = 0;
let offset = Date::now().as_millis();
for n in 0..15000 {
value += (((offset + n) as f64).sin().abs() * 10.0) as i32;
}
value
}
At the 95th percentile for TTFB, Cloudflare was faster than Fastly across every test.

Test | 95th percentile TTFB (ms) |
|---|---|
Cloudflare JS no-op | 469 |
Fastly JS no-op | 596 |
Cloudflare JS hard | 481 |
Fastly JS hard | 631 |
Cloudflare Rust hard | 493 |
Fastly Rust hard | 577 |
The reasons become clearer when you separate the components. On p95 Wait time — the portion tied to on-box compute — Cloudflare held a significant edge on the JavaScript tests. Fastly's Rust performance, however, was competitive, which aligns with Fastly's stated focus on optimizing that workload.

Test | 95th Percentile Wait (ms) |
|---|---|
Cloudflare JS no-op | 123 |
Fastly JS no-op | 123 |
Cloudflare JS hard | 136 |
Fastly JS hard | 170 |
Cloudflare Rust hard | 160 |
Fastly Rust hard | 121 |
The bigger gap shows up in TTFB, and that's not about compute speed. Cloudflare's advantage comes from faster Connect and SSL establishment times, which means Workers code starts executing sooner. Our network stack processes requests more quickly overall, giving us a head start that carries through the entire request lifecycle.

Test | 95th Percentile Connect (ms) | 95th Percentile SSL (ms) |
|---|---|---|
Cloudflare JS no-op | 81 | 289 |
Fastly JS no-op | 88 | 293 |
Cloudflare JS hard | 81 | 286 |
Fastly JS hard | 88 | 291 |
Cloudflare Rust hard | 81 | 288 |
Fastly Rust hard | 88 | 295 |
To validate the Catchpoint findings, we compared them against our own real-user data. The p95 TTFB results for the JavaScript and Rust hard loops confirmed Cloudflare's lead on both. Interestingly, in our dataset, Cloudflare also edged out Fastly on the Rust hard loop for Wait time — a result that didn't appear in the Catchpoint synthetic tests.


The takeaway: Cloudflare's speed advantage isn't just about faster function execution. It's the combination of lower-latency connections and quicker request handling across our entire stack that makes Workers faster end to end.
Why a Faster Network Matters for Developers
Cloudflare’s developer tools are built on top of its global network, and that network’s speed directly translates into application performance. By hosting Pages on every Cloudflare server and deploying Workers across 275 cities with zero configuration, developers get performance gains without extra setup work.
This same network also powers the company’s broader security and performance stack. DDoS protection, WAF, rate limiting, bot management, caching, SSL, and smart routing all run on a single integrated platform. The company’s approach is that having one software stack allows for a wide feature set while keeping performance high across all products—so users don’t have to trade security for speed, or vice versa.



