For a short set of comparable internet speed tests, record the median, the full range and any failed runs. The fastest result shows what happened once; it does not describe every session. An average can also hide a slowdown. Keeping the individual readings makes your summary useful when you compare rooms, troubleshoot a change or contact support.
This guide explains how to summarize your own results. The numbers below are invented arithmetic examples, not measurements of Instant Speed Test, an ISP or a device. For the meaning of download, upload and latency, start with our guide to reading speed-test results.
What the median, mean and best result tell you
The median is the middle reading after you put the numbers in order. With an even number of readings, average the middle two. The arithmetic mean is the sum divided by the number of readings. These definitions follow the NIST explanation of measures of location. A median is less affected by an extreme value, but it does not describe all the variation.
For download or upload throughput, the best reading usually means the highest Mbps. For latency, a lower time is generally preferable, so “best” points in the opposite direction. Label the metric rather than writing an ambiguous “best speed.” Do not average Mbps and milliseconds together.
| Summary | Useful question | What to keep alongside it |
|---|---|---|
| Median | What was the middle result in this set? | Individual readings, range and number of completed tests |
| Mean | What is the arithmetic average of these readings? | Whether one unusual value moves the average |
| Highest throughput | What was the highest Mbps observed? | How often other runs approached it |
| Range | How far apart were the lowest and highest completed readings? | The order and circumstances of the readings |
A five-result worked example
Suppose five completed download tests, under one labelled condition, return 92, 95, 96, 98 and 199 Mbps. They are already sorted. The median is 96 Mbps. Their total is 580 Mbps, so the mean is 116 Mbps. The highest result is 199 Mbps, and the observed range is 92–199 Mbps.
“My connection gets 199 Mbps” leaves out four readings below 100 Mbps. “My average is 116 Mbps” is mathematically correct but also hides the pattern. A clearer note is: “Five completed tests: median 96 Mbps, range 92–199 Mbps; four readings were 92–98 Mbps.” Keep the original order too: it may show whether the unusual reading happened before or after a change.
These five invented readings do not establish a long-term service level or a statistically representative estimate. They demonstrate why a summary needs context. If you have four readings, such as 90, 94, 98 and 110 Mbps, the median is (94 + 98) ÷ 2 = 96 Mbps. You do not pick the larger middle value.
Keep different test conditions in separate groups
A useful summary begins before the calculation. Write down the condition you want to compare: one laptop on Ethernet, the same laptop on Wi-Fi in one room, or a repeated time window. Keep the service and selected endpoint consistent where the tool allows it.
Cloudflare’s discussion of internet measurement explains why observations depend on the measurement method and competing traffic. Running two throughput tests together can make them share a bottleneck. A tidy calculation cannot repair an uncontrolled comparison.
- Separate devices and rooms. Pooling a wired desktop with an upstairs phone obscures the question you are trying to answer. Use our Wi-Fi room comparison for a consistent same-device workflow.
- Separate test services. A result to one destination is not interchangeable with another service’s result. Record the server or endpoint when shown.
- Separate idle and loaded latency. A response time while a transfer runs answers a different question from one measured before it starts.
- Record changes. A VPN, cable, background upload or browser change deserves its own label rather than being silently mixed into the original group.
Use a bounded comparison plan
Decide your small comparison set before starting. For example, compare two completed runs per condition, alternate the conditions if practical, and repeat the comparison later if the difference persists. That is a suggested troubleshooting workflow, not a statistical guarantee or an instruction to run tests continuously.
Allow each test to finish before starting another. Pause your own optional transfers for a controlled baseline, and write down household activity you cannot control. Our measurement method and data-use notes explain what the site’s browser test measures. Check data allowances before repeating bandwidth tests, particularly on a mobile connection.
If your real problem occurs only during an evening upload, collect a separately labelled observation during that activity. A quiet morning baseline can be useful without reproducing the affected condition. The comparison needs both the reading and the symptom.
Do not turn failed tests into zero Mbps
An aborted, timed-out or unavailable result is a different outcome from a completed low reading. Mark the outcome and any displayed error. Do not insert zero into the numerical set merely because the interface did not return a result.
For example, “four completed tests, one unavailable” preserves information that “five tests averaged 80 Mbps” could conceal. At the same time, do not remove a completed low reading simply because it looks inconvenient. Keep it and note the circumstances. If the comparison remains confusing, use the slow-internet troubleshooter to choose the next controlled check.
A blank log you can copy
Use one row per attempted test. An approximate time and room label are usually enough for your own comparison; you do not need a public IP address in a publicly shared log.
| Time and condition | Service / endpoint | Download / upload Mbps | Latency label / ms | Outcome and symptom |
|---|---|---|---|---|
| Fill in | Fill in | Fill in if completed | Idle or loaded; unavailable if absent | Completed, aborted or unavailable; what happened |
Under the log, summarize each comparable group: completed count, unavailable count, median, range and the condition that changed. Preserve screenshots or result identifiers if the service supplies them. This makes the account easier for support to investigate without pretending a small set proves a cause.
Questions about repeated speed tests
Should I report only the fastest result?
Include it as the highest observed throughput, alongside the rest of the set. It can show that a path achieved that rate once, but does not establish that every session will do so.
Does a higher median prove a router setting helped?
A repeatable difference under comparable conditions is useful evidence. Record other changes and repeat the comparison before attributing it to one setting. A small set of observations cannot rule out every competing explanation.
Can I compare today’s median with last month’s?
Yes, if you keep the dates, devices, connections and test method visible. If those differ, describe the change instead of presenting the two numbers as an identical-condition comparison.