Your speed test varies every time because it measures a moving target: a shared ISP path, volatile Wi-Fi, and a test methodology that lasts only seconds. Seeing 180 Mbps, then 95 Mbps, then 220 Mbps back-to-back is usually normal variance — not a broken test. Seeing 400 Mbps on Wi-Fi and 50 Mbps on ethernet is a local problem. The fix is not "run until you like the number"; it is controlling variables (wired link, same server stack, multiple samples) and reading stability metrics alongside peak Mbps. speedtest.doctor uses self-hosted infrastructure at api.speedtest.doctor to reduce CDN bias; our measurement method documents how we aggregate streams and time windows.
Anatomy of a speed test
Most browser tests: (1) pick a server, (2) open several TCP connections, (3) download for 10–20 seconds, (4) upload, (5) display the highest observed rate. Each step introduces noise. Server choice alone can double results when tests use nearby CDN caches instead of your ISP's transit path. TCP slow start means the first second is always lower — some apps clip that away, others do not.
Upload phases often run after download saturated buffers — bufferbloat can depress upload numbers unrelated to your subscribed tier. That is why we measure idle vs loaded ping in bufferbloat tests and the Connection Doctor.
Ten causes of run-to-run variance
- Wi-Fi RF conditions — MCS rate changes every few seconds with interference.
- ISP shared-node congestion — cable upstream especially; peak-hour collapse.
- Background traffic — cloud backup, game patches, security cameras uploading.
- Different test servers — CDN edge vs transit; auto-server rotation hides the shift.
- TCP vs UDP methodology — different apps measure different things.
- VPN on/off — encryption overhead and remote egress.
- Device CPU limits — old phones cannot saturate gigabit in-browser.
- Ethernet negotiation — flaky cable stuck at 100 Mbps half-duplex.
- QoS or parental controls — router shaping by time of day.
- Measurement window length — short bursts favor lucky TCP ramps.
CDN tests vs self-hosted measurement
Popular consumer tests host payloads on CDN clusters geographically close to you. That measures how fast you can pull from a cache across town — useful for marketing, misleading for ISP disputes. speedtest.doctor deliberately probes api.speedtest.doctor endpoints on our measurement network so consecutive runs compare the same class of path. Read more in why speed test results do not match reality.
How much swing is normal?
| Scenario | Typical variance | Action |
|---|---|---|
| Wired, same server, off-peak | ±10–15% | Average three runs |
| Wi-Fi same room | ±20–40% | Improve RF or use ethernet |
| Peak evening cable | ±30–60% | Log with stability |
| VPN enabled | ±25–50% | Test with VPN off for ISP baseline |
Protocol for a trustworthy baseline
- 01Ethernet from PC to router; pause backups and streams.
- 02Three speed tests — morning, evening peak, weekend.
- 03Record download and upload medians separately in test history.
- 04Run stability for 5–15 minutes — variance matters more than one spike.
- 05Check bufferbloat and jitter if calls lag despite high Mbps.
When variance is the symptom
Wide swings with normal averages often indicate bufferbloat or intermittent loss — throughput recovers between drops while VoIP suffers. Use Connection Doctor to correlate metrics. Chronic evening-only variance points to ISP congestion; 24/7 wild swings on wired ethernet warrant cable plant inspection or modem replacement.
Wi-Fi vs wired: stop comparing unlike runs
Phone on 5 GHz and laptop on 2.4 GHz are different networks. Mesh systems add hop latency. Document band, AP name and distance when saving results. Wi-Fi signal test helps explain Mbps scatter without blaming the ISP.
Mobile and browser differences
Mobile browsers throttle background tabs; battery saver caps CPU. Desktop Chrome vs Safari use different network stacks. Compare like with like when tracking variance over time.
Using history and API for trend lines
Single runs are anecdotes; trends are evidence. Save results in test history or push scheduled tests through the Measurement API (/docs). MSPs embed widgets via /widgets so customers see the same methodology every visit.
What to tell your ISP
Support teams dismiss one screenshot. Send median wired throughput, time-of-day, modem model, and stability graphs showing sustained under-delivery versus your tier. Reference independent measurement (api.speedtest.doctor) rather than mixed third-party apps that hit different CDNs each run.
TCP tuning and device limits
Even on gigabit plans, a phone or old laptop may not open enough parallel streams or CPU-decrypt fast enough to saturate the link in-browser. Variance between phone and desktop on the same Wi-Fi is often device-bound, not ISP-bound. Retest on a modern PC with ethernet before concluding the line is inconsistent. Our measurement method uses multi-stream TCP similar across clients so comparisons are fairer than single-thread legacy tests.
Seasonal and weather-related variance
Outdoor plant — aerial coax, damaged junctions — can add noise after storms. Variance that appears only during rain or high humidity is a physical-layer clue, not random test error. Log weather and time when saving test history entries so patterns emerge over weeks. Chronic variance without weather correlation more often points to congestion or in-home queueing.
Accepting good-enough vs chasing numbers
Not every household needs gigabit symmetry. If stability runs show flat lines within 15% of tier, low jitter, and bufferbloat grades pass, chasing an extra 50 Mbps on a speed test is cosmetic. Invest effort in Wi-Fi placement and upload headroom for calls before paying for a higher tier — especially when variance is explained by test conditions rather than the line itself.
Multistream vs single-connection tests
A test that opens one TCP flow measures a different ceiling than one that opens eight. Single-stream results often under-report what your ISP can deliver because each flow has its own slow-start ramp. speedtest.doctor uses parallel streams documented in /method so consecutive runs compare like with like. If you switch between apps that use different stream counts, variance is expected — not mysterious.
Ethernet cable and port negotiation
A damaged Cat5 cable or dirty RJ45 jack can negotiate at 100 Mbps full-duplex while showing "connected" at gigabit in software until the next link flap. Run-to-run variance on wired tests sometimes traces to auto-negotiation retries. Swap cable and port once before blaming the ISP. LAN speed test between two local devices isolates switch and cable issues from WAN variance.
Peak vs off-peak testing habits
Comparing a noon test on Tuesday to a Saturday 8 p.m. test is not comparing the same network conditions. Build a personal schedule: one off-peak wired sample weekly, one peak-hour sample weekly, and a stability run after any ISP truck roll. Over a month the spread between those buckets tells you whether variance is time-of-day congestion or unstable hardware — far more useful than rerunning until you see a favorite number.
Tool quick links
Get a stable picture of your line
Run multiple diagnostics — throughput, stability, bufferbloat — on one platform.
Frequently asked questions
- Why does my speed test give different results every time?
- Each run samples a different instant on a shared network. Wi-Fi retransmissions, neighbor congestion on cable nodes, background uploads, TCP slow start, and which test server you hit all change the number. Short tests exaggerate variance.
- How much variation is normal?
- On a wired connection to a consistent server, ±10–15% between back-to-back runs is typical. Variation above 25–30% or multiplicative swings (50 Mbps then 200 Mbps) suggest Wi-Fi, ISP congestion, or tests routing through different CDN edges.
- Why is my speed test faster at night?
- Off-peak hours have less contention on your ISP's shared infrastructure and fewer devices on your home LAN. Evening streaming and upstream uploads on DOCSIS networks especially inflate variance.
- Which speed test is most consistent?
- Tests that use the same independent infrastructure, multi-stream sustained transfers, and report median—not peak—samples. speedtest.doctor uses dedicated endpoints at api.speedtest.doctor rather than variable CDN caches, improving comparability run to run.
- How do I get a reliable speed baseline?
- Run three wired tests at different times (morning, evening peak, weekend), average download and upload separately, then a stability run. If stability variance is high, investigate bufferbloat and packet loss before calling the ISP.