Internet Speed Test

How to run it, and how to read the result

1. Get off Wi-Fi if you can. If you want to know what the line does, test on Ethernet. If you want to know what your laptop gets, test where you actually sit. They are different questions and they give different answers.
2. Stop other traffic first. A game updating, a cloud sync, someone else streaming — all of it comes out of the same pipe and all of it shows up in this number.
3. Press start and leave the tab in front. Background tabs get throttled, so the test stops itself if you switch away rather than reporting a number it collected while nobody was looking.
4. Read the big number as Mbps, the small one as MB/s. They are the same speed: Mbps ÷ 8 = MB/s. ISPs sell megabits, download managers show megabytes, and that factor of 8 is the single most common misreading of any speed test. 100 Mbps is 12.5 MB/s, not 100.
5. Check the latency block, not just the throughput. Median tells you the typical round trip, p95 tells you how bad the slow ones get, and jitter tells you how unevenly packets are arriving. For games and calls those three matter far more than the headline.
6. Look at the stop reason. "estimate stable" means the test saw a steady number and quit early. "data cap" or "15 s limit" means it ran out of budget first — on a fast line that makes the download figure a floor, not a measurement.

What this test actually measures

The download figure is bytes delivered to this page, divided by wall-clock seconds. Three fetch() requests pull payload.bin at once and each response is read through response.body.getReader(), so every chunk is counted the moment it arrives. That is why the graph fills in progressively instead of appearing at the end: the number is a rolling two-second average, not one big division at the finish line.

The first ~600 ms of the run is thrown away. A fresh TCP connection starts in slow start with a tiny congestion window and doubles it every round trip; TLS costs another handshake; the CDN may need a moment to find the file. Measuring through that ramp would drag the result down by a third or more on a fast link. On a very fast link the opposite problem appears — 600 ms is most of the budget — so the warm-up also ends early once 5 MB have moved, whichever comes first.

"Three parallel connections" is not literally true over HTTP/2, and that matters. Cloudflare serves this site over HTTP/2 or HTTP/3, so the three requests are three multiplexed streams sharing one connection, not three independent TCP flows. More streams still means more data in flight and a fuller pipe, which is why one stream under-reports, but a native speed test opening six real sockets to a nearby server has a genuine advantage this page cannot match. The gap is usually small on a home connection and large on a very fast one.

The latency figures are HTTP round trips: a one-byte range request to a small file on this origin, twenty times, with two uncounted probes first so the connection and TLS session are already established. This is not ICMP ping. It includes the server finding and returning the file, and each probe carries a unique query string so nothing is served from a cache — which also means the CDN edge cannot answer from its own cache and a few milliseconds of lookup are baked in. Expect these numbers to sit slightly above what ping in a terminal reports against the same host, and to bear no relationship at all to the ping you see in a game, which is measured against a different server on a different path.

Jitter here is the mean absolute difference between consecutive round trips. If the probes come back at 14, 15, 14, 16 ms the jitter is about 1 ms; if they come back at 14, 60, 15, 70 ms it is around 45 ms even though the median barely moved. That second pattern is what makes a voice call sound like a robot while a speed test still reports a healthy number.

When the number looks wrong

Speed tests are diagnostic, not decorative. If the result is well below what you pay for, work down this list before calling the ISP — in practice the fault is almost never the line.

• Wi-Fi is the bottleneck far more often than the internet is. A router advertising "1200 Mbps" is quoting the sum of both radio bands under laboratory conditions. Two walls, a 2.4 GHz-only client, or a neighbour on the same channel and you are realistically looking at 40–80 Mbps. Run the test once on Ethernet: if the wired number is fine and the wireless number is not, the problem is radio, not the ISP.
• Old hardware caps you before the line does. A 5-year-old phone, a 100 Mbps switch port, a cheap powerline adapter or a Wi-Fi 4 laptop will all top out well under a modern connection. A 100 Mbps Ethernet port reads as a suspiciously exact ~94 Mbps — that flat ceiling is the giveaway.
• VPNs, proxies and "security" suites re-encrypt every byte and add a detour through another continent. Halved throughput and doubled latency is normal. Turn it off and re-test before blaming anything else.
• Something else is using the connection. Console and game-launcher updates are the classic culprit because they deliberately saturate the link. So does a cloud backup, and so does anyone else in the house.
• Your upload is saturated. Downloads need acknowledgements to travel back upstream. If a backup is pinning your upload, your download collapses even though nothing is wrong with it — a classic asymmetric-line failure that looks like a mystery until you notice the latency figures have also gone through the roof.
• Latency high, throughput fine. That is usually bufferbloat: an over-full queue in the router, which no amount of extra bandwidth fixes. Look for SQM or "smart queue" in the router settings.
• Everything looks fine here but a specific site is slow. Then it is not your connection, it is that route or that server. This test only ever proves the path between you and one CDN edge.

Latency and jitter matter more than the big number

Bandwidth decides how fast a large file finishes. Latency decides how quickly anything at all starts, and almost everything you do online is a long conversation of small messages rather than one big file.

Loading a page means a DNS lookup, a TCP handshake, a TLS handshake and then the request — four or more round trips before the first byte of content. At 15 ms that is invisible. At 150 ms the same page feels sluggish on a gigabit line, because the delay is in the waiting, not the transferring. Going from 50 to 500 Mbps changes nothing about that; halving the latency changes everything.

For games it is worse, because the game state is a stream of tiny updates. Throughput is irrelevant — a competitive shooter uses a fraction of a megabit — while every millisecond of round trip is a millisecond of the world being out of date. Jitter is the real killer: a connection that varies between 20 and 90 ms feels worse than a steady 90 ms one, because prediction and interpolation can absorb consistent delay and cannot absorb a moving target. Video calls behave identically; the jitter buffer either grows (adding delay) or gives up (dropping audio).

So the useful reading of this page is: is the download roughly what I pay for, is the median latency under about 40 ms, and is the jitter in single digits? If all three are true the connection is healthy and any remaining slowness lives somewhere else.

Related tools