Methodology
How our speed test works
Every number on our home page comes from the open ndt7 protocol, run against servers operated by Measurement Lab (M-Lab). This page explains each step, what each number means, and the known reasons it may not match another speed test.
1. Choosing a server
After you accept M-Lab's data policy, the client asks M-Lab's locate service for a nearby server. We do not pick the server and we do not run our own test servers. The server name and city appear in the result panel so you can see where you measured to.
2. Download and upload
The ndt7 specification says each direction runs for up to ten seconds over a single TCP connection, using TCP BBR on the server where available. Download is the average rate your browser received data; upload is the rate the server reports receiving data, taken from the server's TCP statistics when available.
A single connection is a deliberate choice by M-Lab: it shows what one ordinary transfer, like a file download, can achieve. Tests such as Speedtest by Ookla open several connections at once and usually pick a server inside or close to your provider's network, so they often report higher numbers on fast plans.
3. Idle latency and latency under load
During the download, the M-Lab server periodically sends its kernel's TCP statistics. We read two of them:
- Idle latency is
MinRTT, the smallest round-trip time the server's TCP stack saw. It is the closest this test gets to an unloaded ping. - Latency under load is the median of the smoothed
RTTsamples taken while the download is running.
The ndt7 specification notes that a large queue building up during the test usually means a bottleneck with an oversized buffer. In plain terms: if latency under load is much higher than idle latency, your connection is likely suffering from bufferbloat, which is what makes calls stutter and games lag when someone else is downloading.
These are TCP round-trip times measured by the server, not ICMP ping and not your game's own ping. They are useful for comparing runs on the same connection, not for comparing with a number another app shows.
4. How we label results
After a run, we compare your numbers with published requirements from the services themselves, such as Netflix's 15 Mbps for 4K and Zoom's 3.8 Mbps upload for 1080p group video. Every threshold we use is listed with its source on the relevant guide. We do not give connections a letter grade.
5. Why your result may differ from other tests
- Different servers. Fast.com measures to Netflix servers, Ookla to its own network of hosts, M-Lab to its research servers. Each is a different path.
- Single vs multiple connections. One connection can be limited by latency and packet loss in ways that several parallel connections hide.
- Browser limits. On gigabit plans, the browser, the device's CPU and Wi-Fi often become the bottleneck before the line does.
- Timing. Evening congestion, other devices and background uploads change every result.
For a deeper walk-through with real examples, read why speed test results change between runs and sites.
6. What happens to your data
M-Lab publishes each test result with the public IP address and timestamp. Speed Check Hub does not store results. Details are in our privacy policy.
7. Code and changes
The site uses the open-source @m-lab/ndt7 JavaScript client version 0.1.4 (Apache License 2.0), served from this site rather than a third-party CDN. When we change how a number is calculated, we update the client version above and note it here.