Why Methodology Matters
A speed test run randomly, on Wi-Fi, in the middle of the day, from an old phone, while someone else is streaming — tells you almost nothing useful. The number you get could be completely accurate, completely misleading, or anywhere in between, and you cannot tell which. Good speed test methodology eliminates confounding variables one at a time so the number you see actually means something you can act on.
The goal is not a high score. The goal is a reproducible baseline you can use to compare against your subscribed plan, against previous results, against Wi-Fi performance in different rooms, and against the results you get during peak vs off-peak hours. That comparison is where the diagnostic value lives.
The Standard Baseline Test
Run this before trying to diagnose any speed-related problem. It gives you the cleanest possible measurement of what your ISP is actually delivering:
- Use Ethernet: plug a laptop into the router with a Cat5e or better cable. Disable Wi-Fi on the laptop so it cannot fall back to wireless. If your laptop has no Ethernet port, use a USB-C to Gigabit Ethernet adapter (avoid USB 2.0 adapters for connections faster than 100 Mbps).
- Close everything else: close all browser tabs, pause cloud sync services (Dropbox, iCloud, OneDrive), stop any active downloads. Check the router admin page for other devices showing high bandwidth usage and pause them if possible.
- Run three tests in succession: use the same test service and the same server for all three runs. Note whether results are consistent — consistent results mean the measurement is reliable; high variability between runs is itself diagnostic (it indicates congestion or instability).
- Record the results: write down or screenshot each result with the timestamp visible. Include: date, time, test service used, server location, download speed, upload speed, latency, and connection type (Ethernet to router).
Variables to Test Systematically
| Variable | Why Test It | What the Comparison Tells You |
|---|---|---|
| Ethernet vs Wi-Fi, same room | Isolates the Wi-Fi overhead from the ISP connection | Difference = Wi-Fi overhead; if large, focus on Wi-Fi, not ISP |
| Wi-Fi near router vs problem room | Isolates Wi-Fi coverage/signal attenuation | Large drop in distant room = signal coverage problem, not ISP |
| Morning (off-peak) vs evening (peak) | Detects congestion-related speed reduction | >30% drop evenings = shared node congestion; call ISP with data |
| Router vs direct modem connection | Isolates router from ISP/modem problems | Better speed directly on modem = router is bottleneck |
| Near server vs distant server | Tests ISP's peering and transit to other networks | Fast nearby, slow distant = peering issue on that route |
| Multiple test services (Ookla, Cloudflare, Waveform) | Detects ISP test-server preferential treatment | Much faster on Ookla than Cloudflare = possible ISP speed test optimization |
Latency and Jitter Are Not Optional
Most people focus entirely on download speed. But for the activities that actually cause frustration — video calls, gaming, streaming instability, VoIP calls — latency and jitter matter as much or more. Record these from every test:
- Latency (ping): the round-trip time to the server in milliseconds. Under 20ms is excellent; 20–50ms is fine for most uses; above 100ms causes noticeable problems on calls and gaming.
- Jitter: variation in latency between packets. A ping that averages 30ms with 2ms jitter is smooth. A ping that averages 30ms with 40ms jitter means individual packets arrive at wildly varying times — this is what causes choppy audio and stuttering video even when the average latency looks fine.
- Loaded latency: use the Waveform Bufferbloat Test to see how latency behaves while the connection is saturated. This is the most real-world relevant measurement for call and gaming quality.
Interpreting Results Against Your Plan
ISPs do not guarantee exactly the advertised speed. Most ISP service agreements promise “up to” the plan speed, with an implicit understanding that real-world performance is lower. A rough rule of thumb for what to expect on a wired Ethernet connection during off-peak hours:
- 90%+ of plan speed: excellent, no reason to contact ISP
- 80–89%: normal, acceptable
- 70–79%: check for background activity, router bottleneck, or test server issues before contacting ISP
- Below 70% consistently on Ethernet during off-peak: worth contacting ISP with your documented test results
Frequently Asked Questions
How many speed tests do I need to run to get a reliable result?
Three tests in a single session give you enough data to average out random variation and spot inconsistency. For diagnosing time-of-day problems, run the same three-test session at two different times — once during your quiet hours and once during the period you notice problems. That gives you a before/after comparison that is meaningful. Thirty random tests over a week with no consistent methodology gives you less usable information than six well-controlled tests.
Does it matter which speed test service I use?
Yes, somewhat. Different services use different server infrastructure and different testing protocols. Ookla (Speedtest.net) is the most commonly used and the one ISPs are most likely to have optimized servers near. Cloudflare's test (speed.cloudflare.com) uses servers that ISPs cannot directly optimize because they are on Cloudflare's own network. Waveform's test adds bufferbloat measurement. For ISP disputes, using multiple services and averaging results is more defensible than a single service. Include the service name in your records so you can compare like-with-like over time.
Why does my speed test result vary between runs?
Some variation is always normal — the internet is a shared, dynamic system and no two measurements are identical. Variation of 5–10% between runs on a wired connection is normal noise. Variation of 30–50% between runs on the same wired connection points to real instability — modem signal fluctuation, upstream congestion, or a failing cable connection. On Wi-Fi, 20–40% variation between nearby runs is common because of channel conditions, competing traffic from neighbors, and radio interference. If Ethernet results are highly variable, that is the unusual finding worth investigating.