Run three speed tests and you will get three answers. None of them is lying — they are measuring different things, and knowing which is which is the difference between fixing the right problem and buying a faster plan you will never see.
One connection cannot fill a fast line
A single connection has to work out how much it can send, starting cautiously and building up, and the round trip to the server caps how fast it can learn. On a gigabit line one stream may only ever reach a third of it. Every serious speed test opens several at once, and so does this one — if a tool does not, it will under-report you badly.
Short tests measure the warm-up
Time the download of a single small file and most of what you measured was the connection getting up to speed, plus the wait before the first byte even arrived. On a quick line that dead air is longer than the transfer. A test has to run for seconds, not milliseconds, and throw the beginning away.
How this one measures
Eight connections at once, run for up to eight seconds each way, with the first 600 ms discarded while the connection is still working out how much it can send. The window is then cut into twenty slices and the slowest 30% are dropped before averaging — Ookla’s trim, which removes congestion, retransmits and the moments a link stalls. Ookla also drops the fastest 10%; we keep them, because their sampling is spiky enough that a burst can read as speed that was never there while ours counts whole chunks and cannot. The page tells you the exact window and how many megabytes it used.
No test can be faster than its server
Every speed test is also a test of the machine on the other end — and a single small file on one web host has a throughput ceiling far below a fast line, which is exactly why a lot of homegrown speed tests quietly under-report a quick connection. This one measures against a distributed, high-capacity network with servers close to you, the same class of backend the big tools use, so both download and upload reflect your line rather than our hardware. If your result still trails your plan, the bottleneck is your connection or the WiFi — not the test.
Distance to the server is not your speed
Speed tests that pick a server in your city will always read higher than one that does not, because less of the internet sits between you and it. That makes them good for measuring your line and poor for comparing tools. What matters is testing the same way twice — which is why the reference reading above is more useful than the raw number.
Your phone is part of the test
An older phone, a browser with forty tabs open, or a laptop on battery saver will all read low regardless of the connection. So will a 2.4 GHz link, which is often what a phone falls back to at the far end of a house even when 5 or 6 GHz is available.
Upload is the half nobody checks
Most plans give you a fraction of your download speed going the other way, and it is upload that carries your video calls and everything a cloud camera records. A line that streams four films at once can still make you unintelligible on a call.
Jitter breaks calls, not slow speed
Latency is how long a round trip takes; jitter is how much that varies. Voices overlap and words clip because of the variation, not the average. It is why a fast connection can still hold a terrible meeting, and why more speed almost never fixes it.