All the Ways a Single Speed Test Can Lie
A speed test result is a snapshot of one connection, to one server, at one moment, from one device, under whatever conditions existed in that second. Every one of those variables can produce a number that does not reflect your actual service. Here is what can inflate or deflate a single result:
| Variable | How It Distorts Results | How to Control It |
|---|---|---|
| Test server location | A server that is 5 miles away via the ISP's own network gives artificially fast results; real-world traffic to distant servers is slower | Test against multiple servers in different cities |
| Time of day | ISP backbone and neighborhood nodes are congested during peak hours (6–10 PM); a 3 AM test shows best-case, not typical performance | Test at different times: morning, evening peak, and late night |
| Connection type | Wi-Fi can be 20–80% slower than Ethernet depending on signal quality and interference | Always test on Ethernet for a baseline; test Wi-Fi separately |
| Background activity | A cloud backup or Windows update running during the test lowers the measured result | Pause all other devices; check router for active high-traffic clients before testing |
| Speed test CDN optimization | ISPs sometimes prioritize speed test traffic differently from regular traffic; Ookla servers are sometimes treated preferentially | Use multiple test services: speedtesthq.com, Cloudflare speed.cloudflare.com, Waveform, nperf |
| Device capability | Old laptops or phones cannot sustain multi-Gbps test rates due to CPU or NIC limits | Use a device with a native Gigabit Ethernet port for testing fast connections |
What a Useful Speed Test Protocol Looks Like
A single test cannot capture variability. A test protocol can. Here is a minimal methodology that gives you usable data:
- Wire up: connect your laptop directly to the router with Ethernet. Disable Wi-Fi on the laptop.
- Pause background activity: disconnect or pause all other devices. Check the router admin page for active high-traffic connections.
- Run three tests in a row: use the same test service and same server location for all three. High variability between runs is itself a signal of congestion or instability.
- Repeat at a different time of day: run the same three tests during evening peak (7–9 PM). A 30–50% difference between peak and off-peak is normal on cable infrastructure. A 70%+ difference is worth reporting to your ISP.
- Test against multiple servers: run at least one test against a server in a different city. If nearby servers show excellent speed but distant servers are significantly slower, your ISP has a peering or transit issue on that route.
- Record the results: write down the date, time, connection type, test server location, and download/upload/latency values. Three tests on Ethernet during a problem period with timestamps is actionable evidence.
Speed Tests Do Not Measure What You Actually Care About
Peak download bandwidth is only one dimension of internet quality. A connection can show 500 Mbps in a speed test and still ruin video calls if it has high jitter or packet loss. Speed tests do not measure bufferbloat (latency degradation under load), packet reordering, or upload/download asymmetry during simultaneous bidirectional traffic — all of which affect real-world quality far more than whether you get 490 or 500 Mbps in a benchmark.
Use the Waveform Bufferbloat Test alongside your speed test to get a more complete picture. It measures latency under load — the thing that determines how smooth calls and gaming are — not just peak throughput. Run a continuous ping during your speed test to see whether latency is stable or spikes while the connection is loaded. If ping doubles or triples during a download, you have bufferbloat regardless of what the speed number says.
Frequently Asked Questions
Why does my speed test show 500 Mbps but Netflix buffers?
Several reasons: the speed test server is close and prioritized by your ISP, while Netflix traffic takes a different route with congestion; your connection has bufferbloat that affects streaming stability but not peak benchmark numbers; the speed test ran during a quiet moment while Netflix peaks during the evening when congestion hits; or your streaming device is on Wi-Fi with a weaker signal than your test laptop on Ethernet. Run a speed test at the same time Netflix is buffering, from the same device, to see if the numbers also drop at that moment.
How do I know if my ISP is throttling specific services?
Run a speed test using a service that tunnels test traffic over a VPN and compare that result with a normal test. If speeds are substantially higher through the tunnel, your ISP may be throttling certain traffic types. Also compare speed tests to different servers — a large drop to a specific network (Netflix, YouTube) that does not appear to all destinations can indicate peering congestion rather than throttling. Document your findings with screenshots and timestamps if you suspect systematic throttling.
What speed test service is the most accurate?
No single service is universally most accurate because it depends on what you are measuring. For raw throughput to a nearby server, Ookla and speedtesthq.com are reliable. For measuring the speed your ISP actually delivers to the broader internet (not just its own servers), Cloudflare's speed.cloudflare.com is harder for ISPs to game because it uses servers on Cloudflare's genuinely distributed network. For bufferbloat and latency-under-load, Waveform's test adds dimensions that raw throughput tests miss entirely. Comparing two or three services from the same session gives the most informative picture.
Can a speed test server be too close?
Yes, and this is one of the most common ways ISPs present misleadingly good results. If the test server is located on the ISP's own network or in a nearby data center they peer with for free, the traffic never traverses the congested parts of their network or their peering links to other networks. You measure the best-case path, not the path your actual traffic uses to reach content on other networks. To avoid this, manually select servers from the test service's list and choose ones located in different cities or operated by different network providers.