How to read a speed test and what it hides

A speed test measures one thing: how fast a single device can move data to and from a single test server, at the moment you press the button. That is genuinely useful, and it is narrower than most people assume. The big number in the middle of the screen is the least informative part of the result. If you are testing because something feels slow, the answer is almost never in one test. It is in the gap between two tests: wired against wifi, or peak hour against midnight. That gap is what tells you whether to move your router or call your provider.

What each number actually means

Download is throughput in megabits per second, not megabytes. There are eight bits in a byte, so divide by eight to get the file transfer speed your browser shows you. A 100 Mbps connection moves about 12.5 megabytes per second at best, which pulls a 5 GB game down in roughly seven minutes. That one conversion clears up most arguments about whether a connection is performing.

Upload is the same measurement in the other direction, and it is the number that decides whether video calls hold together, whether cloud backup finishes overnight, and whether sending a large file takes two minutes or forty. Fiber is usually symmetric, so upload matches download. Cable is deliberately lopsided: a plan sold as 500 down often gives 20 to 50 up. That is normal for the technology, not a fault.

Ping, also called latency, is the round trip time to the server in milliseconds. It describes responsiveness rather than volume. Fiber typically lands in the single digits to the low teens, cable in the 10 to 30 range, mobile networks higher and more variable, and a geostationary satellite link around half a second because the signal physically travels to orbit and back. Under 30 ms feels instant for everything. Above 80 ms you start to notice it in games and voice calls.

Jitter is how much the ping varies between samples. A steady 40 ms is comfortable, while a ping swinging between 15 and 200 ms is what makes a call sound robotic even though the speed test looks healthy. Voice and video need arrival times to be predictable more than they need them to be short.

Packet loss is the percentage of data that never arrives and has to be sent again. The normal figure on a healthy connection is zero. Sustained loss above one or two percent produces stalls, buffering and dropped calls, and it is the single most diagnostic number on the page because a working line simply should not lose packets.

Why the same connection gives a different answer every time

Run four tests in a row and you will get four results. That is expected, and knowing why keeps you from chasing noise.

• A different test server means a different route across the internet, with different congestion on the way.
• Wifi changes second by second as neighbors transmit, as people move around, and as your device drifts between antennas.
• Anything else on your network competes. A console updating quietly in another room will halve your result.
• The testing device can be the bottleneck. An older laptop running a browser based test may run out of processor before it runs out of bandwidth, and a 100 Mbps Ethernet port caps out around 94 Mbps no matter what you pay for.
• Tests that open several parallel connections report a higher figure than tests using one stream, because a single stream is limited by latency as well as bandwidth.

Treat any individual test as a data point rather than a measurement. Run three, take the middle one, and note the conditions.

How to run a test that proves something

1. Start wired. Plug a laptop directly into the router with an Ethernet cable and pause everything else on the network. This removes wifi from the question entirely.
2. Test against the nearest server, then against one in another country. The first shows what your line can do, the second shows how well your provider connects to the wider internet.
3. Now unplug and test over wifi while standing next to the router, on the same device. Compare to the wired figure.
4. Test again in the room where the problem happens.
5. Repeat the whole set at a time when things feel fine and a time when they feel bad, and write both down.

The pattern across those results does the diagnosis for you. Wired matches the plan but wifi beside the router is much lower: the problem is the wifi link itself, usually the band or the channel, which is covered in how wifi channels and interference cause an evening slowdown. Wifi is fine at the router but poor in the far room: that is coverage, and the fix starts with where the router sits in the house. Wired is low at every hour of the day: that is the line, and it is your provider's to explain.

Symptom, metric, likely cause

What the test does not see

Latency under load. Most tests measure ping while the line is idle, which is the easiest possible moment. Run a large download and ping at the same time, and on many routers the delay balloons from 15 ms to several hundred. This is bufferbloat: the router hoards packets in an oversized queue instead of dropping a few. It is why one person downloading ruins everyone else's video call. Some speed tests now report a loaded latency grade, and routers with smart queue management fix it outright.

Protocol overhead. The headline number is measured above several layers of packet headers, so a 100 Mbps line commonly tests at 92 to 97. That is not your provider shortchanging you. Fiber connections often test slightly above the headline figure because they are provisioned with a little headroom.

The server you tested against. Providers frequently host test servers inside their own network. Traffic reaches them without crossing a single congested link, which produces a flattering result that tells you nothing about the path to the service you were actually using.

Traffic shaping. Some networks treat speed test traffic differently, and mobile plans often slow everything after a monthly allowance. Cross check by timing a real large download from a service you use, then converting to megabits by multiplying megabytes per second by eight.

A VPN in the way. Encryption plus a detour through a distant server costs both speed and latency, so always test with it off before concluding anything. There is more on that trade off in what a VPN actually does to your traffic.

Building evidence your provider cannot wave away

Support scripts are built to deflect vague complaints, so bring a table instead of an adjective. Record the date and time, wired or wireless, the server used, and all five numbers. Ten entries across several days, including times when things worked well, is far more persuasive than one screenshot taken in frustration.

Add the modem or ONT status page if you can reach it. It lists signal levels and error counters that an engineer will ask for, and a change in those numbers over time is strong evidence of a physical fault. Then ask precise questions: is there a known fault in the area, what rate is the line synchronized at, and has the local segment been reported as congested. If the answer is that everything looks fine at their end while your wired midnight tests say otherwise, ask for the escalation rather than accepting the reset.

Before you escalate at all, make sure the speed you are chasing is one you need. Plenty of people pay for a gigabit and use a tenth of it, which is worth checking against how much speed a household actually needs or the speed calculator.

What to do next

Do the wired versus wifi pair today. It takes ten minutes and splits the problem in half. If wired is good and wifi is not, the fix is inside your house and costs nothing: move the router, change the channel, or get the far room onto a better band or a mesh node. If wired is bad too, start the log and call with numbers. If both look fine and things still feel slow, the cause is probably a specific device or a single service rather than your connection, and the ordered walkthrough in why your internet is slow picks up exactly there.