How we measure your speed

Transfer tests run through a Cloudflare Worker, not our own server. That means the test measures the connection between you and the wider internet, rather than between you and one machine we happen to rent.

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

An honest caveat about server distance: your test is routed by Cloudflare's anycast network, and it does not always land on the location physically closest to you. We've measured tests from a single connection landing in Dallas, Boston, Miami, and once Marseille. A more distant location inflates your latency reading and can reduce measured throughput. We show which location served your test so you can spot it. We're working on tightening this.

Before timing anything, we open 12 parallel connections for 3 seconds and read as much data as the server will send, recording none of it toward your result. If that suggests a fast connection (over 150 Mbps), we run a second 3-second stage with 48 connections to find the ceiling. We keep whichever stage measured higher, because opening 48 fresh connections costs handshake time that can make the second stage understate a fast line.

This exists to get TCP past slow-start, so the measured phase begins at your connection's real capacity. It also decides how many streams the real test opens. Nothing from warmup reaches your result.

Stream count is chosen from the warmup estimate. Counter-intuitively, fast connections use fewer streams, not more. Each concurrent stream costs real work in the browser, and past a handful that cost outweighs any gain — on a fast line we measured a single stream outperforming 48 by more than double. Slower connections still benefit from more parallelism.

We wait one second after warmup before measuring latency. Warmup deliberately saturates your connection, which fills the queue in your router; measuring immediately afterwards would record how long that queue takes to drain rather than your actual round-trip time.

We then send 21 requests — the first discarded, since it may still be paying connection setup — and time each one. Every request is capped at two seconds, so a single stalled request can't be recorded as a multi-second reading.

• Latency is the median of the 20 measured samples.
• Jitter is the mean of the absolute differences between consecutive samples, the method defined in RFC 3550. It captures how much your latency moves 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.

Sample count matters more than it sounds. Real jitter comes in spikes, and we previously used only three samples — enough for two differences, which miss a typical spike roughly three times out of four. Twenty samples is what Cloudflare's own test uses, and it's what makes the number stable enough to trust.

We open the chosen number of streams and sample total bytes received every 500 ms, for up to 15 seconds.

Early exit: after at least 8 seconds, if the four most recent samples fall within 15% of each other, the result has settled and we stop. You don't wait out the full window for a number that's already clear.

Sample trimming: we discard the slowest 25% of sample windows and combine the rest as total bytes over total time, so longer windows count for more. This is the same family of approach Ookla uses.

We send 256 KB chunks across the chosen number of streams for up to 12 seconds. A chunk counts toward your result only once the server confirms it arrived in full, so nothing is credited that didn't actually make it.

Each stream's speed is measured over its own window, ending at its last confirmed chunk. That detail matters: measuring instead against the full 12 seconds would count time spent sending data that was still in flight when the clock stopped and never got credited — which understated upload by 7–13%, and by more on slower connections. This was a real bug in our own numbers, fixed in September 2026.

If you've just run Ookla, 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 treatment your normal traffic doesn't. Our tests run through Cloudflare's edge network instead.

Our number is closer to what your connection delivers to the internet. Ookla's is often closer to what your connection delivers to your ISP's own equipment. Neither is wrong — they answer different questions.

We run on Cloudflare's network, so it's a fair question why the two don't always agree. The main reason is that we report a different statistic.

Cloudflare reports roughly the 90th percentile of their measurements — close to the best your connection managed during the test. We report a trimmed average, which lands nearer what your connection sustained throughout. On a steady connection these are close. On an unstable one, theirs will read higher, and the gap widens the more your connection fluctuates.

We think the sustained number is the more useful one for deciding whether your connection is doing its job. But we don't think theirs is wrong, and we won't claim to be more accurate than they are.

Being clear about the edges of a measurement is part of the measurement.

• Packet loss. Measuring it properly needs UDP, which a Cloudflare Worker can't send. We don't report it and you shouldn't infer it from our numbers.
• Latency under load, or bufferbloat. We deliberately measure latency on a quiet connection. That makes the number clean, but it means we say nothing about how your connection behaves while it's busy — which is often what actually ruins a video call.
• Very fast connections. Above roughly 800 Mbps, browser overhead becomes a real ceiling. This affects every browser-based speed test, ours included. Treat gigabit readings as approximate.
• The spread. We report one number per metric, not a distribution.