A household calls support, reports a speed of forty megabits on a five hundred megabit plan, and is asked to run a test. The test is run on a phone, over Wi-Fi, in a room two walls away, while a television streams. It reads sixty. The case is closed as within tolerance, and the actual problem remains unexamined.
Speed tests are the only evidence most households will ever produce, and most of them are run in a way that measures the wrong thing. A method that takes fifteen minutes produces numbers a provider can act on.
What does a speed test actually measure?
The throughput between your device and a specific server, over a path that includes your network, the provider’s network and the internet. It is a measurement of a route at a moment rather than a property of the line, which is why two tests can disagree substantially.
Understanding that changes how the results should be read. A low figure is evidence of a slow route, and only repetition and variation can attribute it to the provider.
Why does Wi-Fi have to be excluded?
Because it introduces a variable the provider cannot see and the household can fix. A wireless link can lose half the throughput at the far end of a house, and the provider has no way to distinguish that from a line problem. Wired testing removes the ambiguity in one step.
One ethernet cable, borrowed if necessary, is the most valuable diagnostic tool a household can own. Nothing else changes the quality of a support conversation as much.
When should the test be run?
At the time the problem occurs, which for most households is the evening. A test at eleven in the morning measures a network that is not under load, and a result from that hour says nothing about the eight o’clock experience that prompted the call.
Running the test at both ends of the day is better still. The pair of figures separates contention from a fault more reliably than either figure alone.
How many tests are enough?
Three at peak time on three different days is a reasonable minimum. A single low reading can be a server problem, a background download or a momentary blip. A pattern across days is evidence.
Recording the time, the server and the figure each time produces a small table. That table is the document that moves a case forward, and it takes less effort than a phone queue.
Which server should be used?
One close by, and ideally the one a provider’s own tool uses. Testing against a distant server measures the internet rather than the line, and a congested test server produces a low figure for a healthy connection.
Running the same test against two servers and taking the higher result is a reasonable practice. The lower result describes the test infrastructure, and the higher one is closer to the line’s capability.
What should be closed before testing?
Everything that transfers data: backups, cloud sync, updates, streaming, and any device that reports to a server continuously. A single photo upload can consume the upstream and skew the downstream through the acknowledgement effect.
Checking the router’s traffic graph before testing is faster than closing applications one by one. Where the graph is busy, the test is measuring the household’s own activity.
Does a VPN distort the result?
Yes, typically reducing throughput by ten to thirty percent and adding latency. Testing with the tunnel disabled gives the line’s figure, and testing with it enabled gives the figure the household actually experiences. Both are useful, and they answer different questions.
Reporting the two figures side by side prevents an argument about which one is real. They are both real, in different configurations.
What other numbers are worth recording?
Latency, jitter and packet loss, all of which most test pages report below the headline figure. A line with excellent throughput and visible packet loss will feel broken, and the loss is the actionable finding.
Upload deserves the same attention as download. Many tests report it in smaller type, and it is frequently where the actual constraint sits.
How should the results be presented to a provider?
As a table: date, time, connection type, server, download, upload, latency, jitter. Then a sentence describing what the household was doing and what it experienced. That combination removes every reason for a support agent to ask for a retest.
Attaching screenshots is optional once the table exists. The table is more readable and harder to dispute than an image.
What if the provider’s own test disagrees?
It happens, because provider tools sometimes test to a server inside their own network, which bypasses the congested part of the path. A figure from an internal server can be excellent while the real internet experience is poor.
Testing to a general-purpose server as well as the provider’s own resolves this. Where the internal test is good and the external one is not, the problem is at the interconnection rather than on the line.
Does the browser affect the result?
Somewhat. A browser running many tabs, extensions or a hardware-accelerated page competes for resources, and an older machine can be the limiting factor on a fast line. A dedicated application or a command-line transfer removes the browser from the equation.
For most households the browser is adequate up to a few hundred megabits. Above that, the device and the browser start to matter more than the network.
Can a test be run without a browser?
Yes, by downloading a large file from a fast host and timing it, or by using a command-line tool that reports the transfer rate. The result is cruder and entirely independent of the test site’s infrastructure.
This is useful when a provider disputes a browser-based figure. A timed download is difficult to argue with and easy to reproduce.
What does a good result look like?
Within about ten percent of the plan at peak time on a wired connection, with low jitter and no packet loss. A result at ninety percent is normal and not a fault; overheads exist and they are not a conspiracy.
Where the figure is materially below the plan at peak time and the wired test is clean, the line or the network is the cause. That is the point at which a formal fault is justified.
How often should a household test?
When something feels wrong, and once after any change of plan or equipment. Routine testing is unnecessary for a connection that behaves, and it encourages the anxiety that broadband marketing thrives on.
The exception is the first fortnight of a new contract, when the cooling-off window is open. Two tests in that period are the evidence that makes a cancellation decision straightforward.
What is the single most common mistake?
Testing over Wi-Fi and blaming the provider. It is not laziness exactly, it is convenience, and it produces a number that describes a room rather than a connection. One cable removes the error entirely.
Everything else in this article is refinement. The cable is the method.
Can a test be trusted on a busy home network?
Only if the household is quiet when it runs. Two people streaming and a backup service syncing will distort both directions, and the result will describe the load rather than the line. Asking everyone to stop for five minutes is the least popular and most effective instruction in this article.
Where that is impossible, the router’s traffic graph shows whether the line was busy during the test. A figure recorded at forty percent utilisation is not a measurement of capacity, it is a measurement of forty percent utilisation.
Should a test be repeated after a router change?
Yes, and the two results should be kept. A before-and-after pair answers the question that hardware purchases always raise, and it takes twenty minutes. Without the pair, a household spends money and relies on an impression.
The same applies after a plan change. A figure from before the upgrade and one from after it is the only way to know whether the money bought anything the household can use.
What about the provider’s own testing app?
Useful as a second opinion and unreliable as the only one, because it may test to a server inside the provider’s network. Where its figure is much better than an external test, the difference describes the provider’s interconnection rather than the line.
Running both and reporting both is the fair approach. A provider can explain a gap between them, and the explanation is usually the most informative thing in the whole conversation.
A measurement is only evidence if the conditions are written down beside it, and most broadband arguments are really arguments about conditions. What would your own line look like if you tested it properly tonight?