How we measure your speed

Transfer tests run through a Cloudflare Worker, not our server. The Worker runs at the Cloudflare location geographically closest to you — typically within 50 miles. This matters because the test measures the connection between you and the internet, not between you and a machine we happen to rent.

Ookla's model lets ISPs host their own test servers. A well-placed ISP server can make a throttled connection look faster than it is. We don't give ISPs that option.

Before timing starts, we open 8 parallel connections and push 1 MB of data through them without recording anything. This saturates TCP slow-start and gives your connection time to ramp to its real capacity.

Without warmup, the first few seconds of a test show artificially low speeds — TCP is still negotiating how fast to go. Most speed tests skip this step. We don't.

We open 8 parallel download streams and sample throughput every 500 ms for up to 10 seconds.

Early exit: if the last 4 samples are within 15% of each other, the result has stabilised and we stop early. Fast connections finish in 3–4 seconds. You don't wait 10 seconds for a result that's already clear.

Sample trimming: we discard the bottom 25% of samples — the ones collected while TCP was still ramping up. The remaining samples are averaged to produce your download speed.

If you've run Ookla before running this test, our number is probably lower. That's not a bug.

The biggest reason is server placement. Ookla lets ISPs host their own test servers, often inside the ISP's own network. Traffic to those servers never touches the open internet — it gets the red-carpet treatment your normal traffic doesn't. Our tests run through Cloudflare's edge network, the same path your actual downloads and video calls use.

Our number is what your connection delivers to the internet. Ookla's number is often what your connection delivers to your ISP's own equipment. Neither is wrong. They're measuring different things.

If you want to know whether your ISP is holding up their end of the deal for real-world usage — streaming, remote work, video calls — our number is the one that tells you.

We send 4 parallel upload streams of 256 KB each, up to 10 seconds. Upload is simpler than download: total bytes sent divided by elapsed time, with no sample-by-sample trimming needed since there's no slow-start equivalent on the upload side.

We send 3 ping requests to our server and record the round-trip time for each.

• Latency is the median of the 3 samples — more stable than a single reading and not skewed by an outlier.
• Jitter is the mean of the absolute differences between consecutive samples — the same method defined in RFC 3550. It captures how much your latency bounces around from one request to the next. A connection with 20 ms latency and 18 ms jitter is far worse for video calls than one with 40 ms latency and 2 ms jitter — jitter is the number most tools don't show you.