Why Do Speed Test Results Differ Between Sites?

The Mystery of Inconsistent Speed Tests

Run a speed test on three different websites and you'll likely get three different results. This isn't because the tests are broken — it's because they measure different paths through the internet. Here's what's actually going on.

The short version: a speed test does not measure "your internet". It measures the throughput your device achieved to one specific server, over one specific route, during one specific ten-second window, using one specific method. Change any of those four variables and the number changes legitimately. Once you know which variable moved, the discrepancy stops being mysterious and starts being useful diagnostic information.

1. Server Location Is Everything

Every speed test measures the connection between you and a test server. Speedtest.net often picks a server inside your ISP's own network, sometimes in your own city — the shortest possible path. Other tests route to a data center hundreds or thousands of kilometers away.

A ping of 13ms to a server in your city versus 90ms to one in another country isn't a contradiction — they're both real measurements of different routes. That's why a good test shows you which server it used.

There is a second, subtler effect here. A test server hosted inside your ISP's network never touches the ISP's expensive external links. It measures the health of the access line into your home and nothing else. A test server sitting in a neutral data centre crosses your ISP's core, its peering or transit links, and the destination network. Both numbers are true. Only the second one predicts how a game server or streaming service will actually behave.

2. Your ISP's Routing Decisions

ISPs decide how traffic leaves their network. Some route traffic to major CDNs through distant exchange points — your data might travel to Frankfurt or Amsterdam even when the provider has a server nearby. This affects latency-sensitive measurements far more than bandwidth.

Routing is also asymmetric: the path your packets take outbound is not necessarily the path the replies take back. That is why a route can look short on a map and still measure high, and why two tests to servers in the same city can report different pings.

3. TCP Needs Time (and Distance Hurts)

Download and upload speeds are also affected by distance. TCP, the protocol carrying your data, accelerates gradually — and the farther the server, the longer each acceleration step takes. On a long route, a 10-second test may end before your connection ever reaches full speed. Upload suffers the most.

The mechanism is the congestion window. TCP starts cautiously and grows its sending rate based on acknowledgements coming back from the far end. Every growth step costs one round trip, so a 10ms path ramps up roughly ten times faster than a 100ms path. On a gigabit line to a distant server, a short test can spend most of its duration still accelerating, and the reported average lands well below the line's real capacity — even though nothing is wrong.

4. Test Design Differences

Parallel connections: Most modern tests open multiple streams to saturate fast links. Single-stream tests report lower numbers on gigabit lines.
Test duration: Short tests favor burst speeds; longer tests show sustained throughput.
Measurement method: Some report peak speed, others the 90th percentile or average.
Overhead accounting: Some tests report payload throughput, others include protocol overhead. Headers for Ethernet, IP, TCP and TLS consume a real slice of every packet, which is one reason a "1 Gbps" line rarely tests at a clean 1000 Mbps.
Warm-up handling: Tests that discard the first second of data report higher figures than tests that average everything from the first byte.

What Each Factor Actually Changes

Use this to work out which number to trust for which purpose.

Factor	Effect on download/upload	Effect on ping
Server distance	Large on long routes and short tests; small once the connection is fully ramped	Large and unavoidable — physics sets a floor
On-net vs off-net server	On-net usually reports higher	On-net usually reports much lower
Parallel streams	Large on fast lines	None directly, but heavy streams can inflate latency under load
Test duration	Moderate — short tests flatter bursty connections	Minimal
Wi-Fi vs Ethernet	Often the single biggest client-side factor	Adds variability more than average delay
Time of day	Moderate to large at peak hours	Large at peak hours on congested links

5. The Bottleneck May Be Your Own Device

Plenty of "wrong" results never leave the house. Before blaming a test, rule out the obvious ceilings:

Wi-Fi. A device two rooms away negotiates a lower radio rate and shares airtime with every other client. This alone explains most 300-vs-900 Mbps arguments.
An old Ethernet port or cable. A 100 Mbps port, or a damaged cable that has quietly renegotiated down, caps you at roughly 94 Mbps of usable throughput forever.
CPU and browser. Encrypting a multi-gigabit stream is real work. Older laptops, low-power tablets and heavily loaded machines cap out before the network does.
VPNs and security software. Any tunnel or inspection layer adds encapsulation overhead and processing latency to every packet.
Background traffic. A console downloading an update in another room is competing for the same line during your test.

A quick sanity check: if two tests disagree wildly on Wi-Fi but land within a few percent of each other over Ethernet, the tests were never the problem. The radio link was, and every wireless result you have collected so far describes your Wi-Fi rather than your internet connection.

6. Ping Numbers Differ for Their Own Reasons

Two tests can report the same download speed and very different pings, because the latency figure depends on how it was measured, not just where. A traditional tool sends ICMP echo requests; browser-based tools measure HTTPS round trips instead. Routers sometimes deprioritise or rate-limit ICMP, so those two methods can legitimately disagree by a few milliseconds in either direction — we cover the trade-offs in ICMP vs HTTP ping accuracy.

CheckPing measures warm HTTPS round-trip time from your browser to nearby cloud endpoints. That is a proxy for network latency rather than a raw ICMP ping, but it has a practical advantage: it travels the same kind of path your games and applications actually use, including TLS-terminating edge infrastructure. The important discipline is to compare like with like — the same tool, the same server, the same connection type — rather than treating one site's number as the truth and another's as an error. If you mainly care about latency rather than throughput, remember that a speed test and a ping test answer different questions: one tells you how much data the line can move, the other tells you how quickly it reacts.

How to Compare Fairly

Use a wired connection — Wi-Fi is the #1 source of misleading results.
Close background apps and downloads on every device.
Run each test 2-3 times and compare medians, not single runs.
Check which server each test used before comparing pings.
Test at the same time of day. A 14:00 result and a 21:00 result are two different measurements of two different network conditions.
Disable any VPN, proxy or DNS filtering layer for the duration of the test, then re-enable it and test again if you want to measure the cost of running it.
Record the numbers with timestamps. A single result proves nothing; a pattern across a week proves quite a lot. Our guide to testing your internet speed correctly covers the full method.

When a Difference Is Actually a Problem

Most discrepancies are normal. These are the ones worth escalating:

Every off-net test is slow while the ISP's own test server is fast. Your access line is healthy but the ISP's onward capacity or peering is not.
Results collapse only during specific hours. That is a congestion pattern, and it needs timestamped evidence rather than a phone call describing frustration.
Wired results are far below the plan on every test, at every hour, to every server. That points at the line, the modem, or a misconfigured port rather than at test methodology.
Download is fine but latency triples whenever anything transfers. That is not a speed problem at all — see our bufferbloat guide.

Want to see it in action? Run a test on CheckPing — we show you the test server location so you know exactly what you're measuring.