Why Three Speed Tests Give Three Different Numbers

Three answers, all of them defensible

Run a test on three different sites within a minute and you may see 300 Mbps, 180 Mbps and 90 Mbps. It is tempting to assume two of them are broken. In practice each one is answering a slightly different question, and the spread between them carries more information than any single number does.

One is measuring how much capacity the line can carry when it is deliberately saturated. One is measuring how fast a single real-world download will travel. One may be measuring a path that never leaves your provider’s own network. Those are three legitimate quantities with three legitimate uses.

Parallel connections change the ceiling

A single TCP connection needs time to ramp up to the line’s full capacity. Open eight or sixteen at once and each one ramps in parallel, so the aggregate reaches the ceiling far faster — and over a short test, that difference is large. Multi-thread tests therefore usually report higher numbers, and they are the right tool when the question is “did I get the capacity I paid for.”

Single-thread tests report lower numbers and are the right tool when the question is “how fast will this one download actually go.” A video stream, a game download, a file from a CDN and a video call are all single-stream in practice. The gap between the two methods is not measurement error; it is the difference between a capacity figure and a delivery figure.

Latency amplifies the effect. The higher the round-trip time, the longer a single connection spends ramping up, so high-latency links — satellite, some fixed wireless, long international paths — show the widest spread between single and multi-thread results.

Server placement decides which route you measured

Different tools use different server networks. Some pick the nearest available endpoint, some use a content delivery network tied to a specific service, and some use servers hosted inside an internet provider’s own network. Each choice measures a different path.

A test to a server inside your provider’s network never crosses an interconnect, so it can legitimately report the best number you will ever see — and it says nothing about how traffic reaches services outside that network. A test against one content provider’s CDN tells you how that provider will perform, not how the internet in general will perform. Comparing two tools that use different endpoints is comparing routes as much as connections.

The biggest source of error is usually local

Methodology differences get the attention, but in day-to-day testing the largest errors come from the environment:

• Wi-Fi instead of Ethernet. Wireless adds latency, jitter and variability that grow with distance, walls and the number of devices sharing the band. On a fast plan, a wired test and a wireless test in the same room can differ by a wide margin.
• Background traffic. A cloud sync, a system update, a game patch or someone else’s 4K stream consumes capacity during the test window.
• Browser extensions and VPNs. Both sit in the path and can throttle or reroute test traffic.
• Time of day. On shared-media connections the same test run at 10:00 and at 21:00 measures two different networks.

Reading a number with context

A speed test measures one path, to one server, at one moment, using one transfer method. It does not prove that every site will load quickly, that a game server will feel responsive, that the home network is configured well, or that capacity will hold at peak hours. Treat a result as a diagnostic snapshot and treat the method as part of the result — a number without its conditions is not a measurement.

Also worth separating: throughput and responsiveness are independent. A very high capacity line with 200 ms of latency to the nearest CDN feels worse for interactive work than a modest line with 10 ms. If the complaint is “it feels slow,” the Mbps figure is often the least useful number on the screen.

A repeatable testing routine

Standardising the conditions matters more than which tool you pick.

1. Connect by Ethernet where possible. If you must use Wi-Fi, stay in the same room as the access point and use the 5 GHz or 6 GHz band.
2. Close everything that moves data — backups, sync clients, updates, streams — on the test device and on anything else sharing the connection.
3. Test with a clean browser profile, no extensions, no VPN.
4. Run three tests and take the middle result rather than the best one.
5. Record the time of day, and repeat at the busiest hour you normally use the network. The difference between the two is the figure that predicts your real experience.
6. If two services disagree, test both against the same nearby server before concluding the line is at fault.

Do this once at mid-morning and once in the evening, and you will have a more accurate picture of your connection than any single headline number can give you.