A larger winning share, not a faster whole website
In its October 2 report, Cloudflare says it ranked fastest for TCP connection time on 74% of the 1,000 largest networks in August, versus 60% in April. This is the company's comparison, not an independent benchmark.
Subtracting the published percentages gives 14 percentage points. Dividing that difference by the April share gives approximately 23.3% relative growth in winning network share. Neither calculation says connections became 23.3% faster, much less that a website loads that much faster. A change in rank is a different quantity from a change in elapsed time.
Cloudflare also reports 150 additional winning networks. The rounded percentages imply roughly 140 net additions if applied literally to 1,000. Without raw counts, membership and transition data, we cannot reconcile those statements; do not silently replace one with an invented explanation.
Source notes: 1. Editorial interpretation and illustrative calculations are identified separately.
What the metric can and cannot tell you
Providers are ranked by the trimean of connection times: the 25th, 50th and 75th percentiles, with double weight on the median. The top-network selection uses APNIC estimates of user populations.
Consider an invented distribution with quartiles of 15, 20 and 35 milliseconds. Its trimean is (15 + 2 × 20 + 35) / 4 = 22.5 milliseconds. This single number describes the middle of the distribution, not the slowest visits. Two providers could have similar trimeans while delivering different experiences to the unlucky minority.
Connection establishment is only one part of a navigation. W3C Navigation Timing exposes separate response and document-processing milestones. A network leaderboard therefore cannot identify whether a slow checkout is waiting for its application, downloading content or doing work in the browser.
Source notes: 1, 3. Editorial interpretation and illustrative calculations are identified separately.
Counting networks is not counting your readers
Geoff Huston's 2024 APNIC explanation describes population estimates assembled from demographic and Internet-adoption data plus advertisement-based sampling mapped to networks. It identifies assumptions about ad distribution and people using one ISP, alongside problems such as proxies, ad blocking and uneven coverage. These estimates are useful context, not a census of every visitor.
Selecting networks by estimated population does not make the final winning percentage user-weighted. In a count-based ranking, each selected network contributes one result even when their populations differ substantially. Nor is estimated population identical to the number of sessions your service receives.
In a hypothetical ten-network sample, a provider winning nine networks with 100 users each but losing one with 9,100 users wins 90% of networks while winning networks serving only 9% of the users. That extreme illustration is not Cloudflare data; it shows why the denominator matters before applying a global claim to a local audience.
Source notes: 2. Editorial interpretation and illustrative calculations are identified separately.
More observations do not automatically settle comparability
Sampling now includes a small fraction of eligible free Challenge Pages alongside Cloudflare-branded error pages. The April-to-August comparison therefore coincides with a measurement change.
More observations can reduce random uncertainty without removing selection bias. A browser encountering a challenge or error is not automatically representative of every successful visit. A changed mixture of networks, devices or times of day can also move an aggregate ranking even if underlying routes stay unchanged.
A stronger trend test would keep the network set and sampling rules constant, then publish results separately under old and new collection methods. Per-network sample counts and uncertainty intervals would help distinguish a durable lead from noise. An isolated one-millisecond advantage is not a guarantee for the next request or a reason to promise users a visible improvement.
Source notes: 1, 2. Editorial interpretation and illustrative calculations are identified separately.
A proposed evaluation starts with the actual workflow
This is a suggested test plan, not work Lumacta has performed. First choose representative tasks: reading an article, searching, signing in or completing a transaction. Agree in advance which audience segments and failure outcomes matter. Keep content, application behavior and cache policy comparable across any candidate environments.
Use browser navigation records to separate response arrival from document readiness and the load event. W3C defines those as distinct milestones; its September 2026 Level 2 publication remains a Working Draft. A load-event timestamp is not proof that every application interaction works, so pair timings with completion checks.
Repeat matched observations across the access networks, devices and hours relevant to the audience. Document connection reuse and cache state instead of mixing first visits with warm returns. Report sample sizes, distributions and failed attempts, not only whichever average flatters a provider.
Source notes: 3. Editorial interpretation and illustrative calculations are identified separately.
Use an advantage only where it changes an outcome
Suppose a hypothetical trial finds a two-millisecond connection advantage but no meaningful improvement in completed searches or slowest visits. The rational next step may be application profiling, not migration. Conversely, a consistent improvement in a poorly served audience segment could justify a scoped follow-up even when the global leaderboard barely moves.
Set a decision rule before testing: the minimum useful improvement, acceptable failure rate and operational costs of a change. Check whether the observed effect repeats, rather than treating a narrow lead as permanent. Reliability, support, configuration risk and reversibility belong in that decision too.
The report is useful as a question generator: where might delivery be limiting our users, and what would convincing evidence look like? It is not a substitute for answering those questions on the service people actually use.
Source notes: 1, 3. Editorial interpretation and illustrative calculations are identified separately.
Sources & Methods
We read Cloudflare's October 2 report, Geoff Huston's November 11, 2024 APNIC explanation, and W3C's September 1, 2026 Navigation Timing Level 2 Working Draft. Calculations and evaluation steps are Lumacta analysis; examples are hypothetical, not measurements. Lumacta uses Cloudflare Pages for hosting. We have not compared providers and this article is not a purchase recommendation.
- Cloudflare: 2026 Birthday week network performance update — October 2, 2026 — Vendor report and measurement description
- APNIC: How we measure ISP user counts — Geoff Huston, November 11, 2024 — Primary explanation by the measurement author
- W3C: Navigation Timing Level 2 — Working Draft, September 1, 2026 — Primary web-performance specification draft