Why speed-test results vary
Understand how server distance, Wi-Fi, other traffic, devices and test design create different but potentially valid results.
Start with the free diagnostic steps. Affiliate links appear only where a product category could address the problem identified in this guide.
Key takeaways
- A speed test measures one device-to-server path at one time, not an abstract permanent line speed.
- Different tests can use different servers, transfer sizes, parallel connections and result calculations.
- Control the device, location and traffic, then compare a series instead of choosing one extreme.
Every test measures a particular path
A browser test includes the device, browser, Wi-Fi or Ethernet link, router, access connection, provider network, inter-network route and the selected test server. Change any part of that path and the result can change. Two services may both be functioning correctly while reporting different numbers because they terminate in different places or use different routes.
Latency is especially sensitive to distance. Light travels quickly but not instantly, routes are not straight and every network hop adds processing and possible queueing. LumaProbe’s current server is in the United Kingdom. A visitor in a distant region should not compare its latency directly with a neighbour using a nearby test node.
Test design changes the number
A short single transfer may not fully use a high-capacity line because transport protocols need time to increase their sending rate. Multiple parallel transfers can fill the path more quickly, but they also represent a heavier workload. Some tests report the highest interval, others an average or percentile. Upload size, warm-up time and discarded samples also differ.
LumaProbe downloads three six-mebibyte blocks in parallel, uploads one six-mebibyte block and reports a median for idle and loaded HTTPS latency. FAST.com uses globally distributed Netflix servers and focuses on a simple download result while exposing more detail on request. Neither design should be treated as a contractual modem reading.
Wi-Fi is a changing shared medium
Wi-Fi capacity changes with signal level, walls, interference, channel use, device capability and other stations taking turns on the same radio. Moving a laptop, closing a door or changing its orientation can alter the link. A phone and laptop beside one another may support different standards, antenna arrangements and channel widths.
Use Ethernet as a control where practical. If Ethernet is repeatable but Wi-Fi varies by room, investigate placement and coverage. If both move together, look at shared traffic, the access line, provider routing or server conditions. An Ethernet control narrows the fault; it does not make every upstream factor constant.
Other traffic competes with the test
Streaming, cloud backup, operating-system updates, security-camera uploads and another speed test share capacity. A background upload can also create queueing that raises latency for everything else. Task Manager or router traffic information may reveal activity, but avoid installing unknown monitoring software merely to chase one unusual result.
For a maximum-capacity comparison, pause avoidable transfers and test one device. For a real-experience comparison, deliberately test during the normal busy period. Both questions are valid, but they answer different things. Record which conditions you used so later results are comparable.
The device and browser impose limits
Processor load, memory pressure, battery-saving settings, VPNs, antivirus inspection, browser extensions and network-adapter drivers can affect measured throughput. A USB adapter on a slow port or a negotiated 100 Mbps Ethernet link can become the bottleneck. A very old device may never demonstrate the full capability of a new package.
Repeat in another current browser and on another capable device before assuming the line is capped. Do not disable security software permanently; a brief controlled comparison is enough when safe and permitted. Managed work devices should keep organisation policies intact.
Build evidence rather than chasing a perfect score
Run at least three tests with the same device, location, connection type and traffic conditions. Keep the median pattern and note time of day. Then change one variable: move beside the router, connect Ethernet, pause a backup or use the provider’s own checker. The difference between those groups is more diagnostic than the single best result.
When reporting a fault, include the package or expected range, wired and Wi-Fi results, timestamps, device, official-status check and any router-light changes. Explain which boundary the test covers. That is more credible than presenting one screenshot as proof of the exact cause.
Recommended next checks
Compare results beside the router, in the problem location and over Ethernet where possible. Repeat under the same conditions rather than relying on one run. LumaProbe’s browser measurements describe the complete path to its server, so use them to narrow the fault—not as a substitute for a provider line diagnostic.
Sources and further reading
- FAST.com: what the test measures and how results are calculated
- Ofcom: get more from your broadband
- LumaProbe test methodology
- LumaProbe Wi-Fi speed test
External guidance can change. Sources and links for this article were checked on 28 July 2026.
More help
Browse all internet and Wi-Fi guides, read how LumaProbe tests connections, or report a correction through LumaContact.