How we measure
Every number on this site comes from the steps below. Nothing is estimated, and when a measurement fails the test says so instead of showing a value.
Latency and jitter
The test sends 12 small requests to the server and times each one. The first 2 are always discarded: they pay for opening the connection (DNS, TCP, TLS) and say nothing about the steady-state delay.
Latency is the median of the remaining requests. Jitter is the mean difference between each request and the next one, in the order the answers arrived. The order matters: if the samples were sorted by value first, neighbours would always be close and jitter would come out lower than it is.
If no request is answered, the test stops with an error message. There is no "default" latency.
Download and upload
For download, the browser requests blocks of data and counts the bytes as they arrive. For upload, it sends blocks and listens to the browser’s progress event, which reports how many bytes have left while the request is still running. A slow line therefore produces samples too, instead of reading zero until a block finishes.
Every 200 ms the test computes the speed of that interval. Samples from the first second are discarded (the ramp-up) and the result is the median of the rest. It is not the peak and not a high percentile.
If no bytes are transferred, for example because the server refused the requests, the test reports the failure. It does not show 0 Mbps as if it were a measurement.
The adaptive plan
Each stage starts with 3 probing connections. After 200 ms the test looks at how many bytes went through and picks the plan in the table. Slow lines get small blocks and more time; fast lines get more connections and less time, so the test does not transfer more than it needs. The server caps every request at 50 MiB.
| Speed seen in the first 200 ms | Connections | Block per request | Stage length |
|---|---|---|---|
| below 5 Mbps | 1 | 64 KiB | 8 s |
| 5 to 25 Mbps | 1 | 512 KiB | 7 s |
| 25 to 100 Mbps | 2 | 2 MiB | 5 s |
| 100 to 500 Mbps | 4 | 8 MiB | 3 s |
| 500 Mbps or more | 4 | 16 MiB | 2 s |
The light test puts a ceiling on that plan: at most 3 s per stage and 2 connections. It switches on by itself when the browser reports a mobile or data-saving connection, and can be switched off. The total transferred is shown after each test; the figure counts request payloads, without HTTP headers.
Bufferbloat
While the download runs, the test repeats the latency request every 700 ms. The median of those requests is the loaded latency. Bufferbloat is that value minus the idle latency, and the grade follows the scale below.
| Grade | Latency added under load |
|---|---|
| A+ | up to 5 ms |
| A | up to 15 ms |
| B | up to 35 ms |
| C | up to 70 ms |
| D | up to 150 ms |
| F | above 150 ms |
Limits of the method
- Latency is the time of an HTTP request, not an ICMP ping. It includes some browser overhead.
- Packet loss is not measured: it would need UDP, which a web page cannot send directly.
- The server is the Cloudflare location your network reaches first, not a server inside your provider. Tests hosted by the provider tend to show higher numbers.
- Wi-Fi is part of the measurement. To judge the plan you pay for, test over a cable.
- Other tabs and devices using the line during the test lower the result, which is exactly what the bufferbloat figure is meant to reveal.
- The sentences per use (games, 4K, calls) are derived from the numbers by fixed rules in the code. They are a reading of the result, not a guarantee for any specific service.
Data and privacy
The server accepts test requests only from this site’s own pages and limits how many each IP address can make per minute; the IP is used for that decision and appears in no response. The provider, city and server code shown on screen come from Cloudflare’s connection metadata; when they are missing, the screen shows a dash. The history stays in your browser. Details in the privacy policy.
Questions about the method
Why a median and not an average or a peak?
A peak shows the best 200 ms of the test, which a connection may reach once and never hold. An average is dragged down by a single stall. The median of the samples after the warm-up is the speed the line was at or above for half of the test, which is the closest single number to what a long transfer experiences.
Why is latency measured with HTTP requests?
A web page cannot send ICMP or raw UDP packets. A small HTTP request to an endpoint that answers with no content is the closest available probe. It includes a little browser and TLS overhead, so we discard the first two probes, which also pay for opening the connection, and call the result latency rather than ping.
Which server does the test use?
The test endpoints run on a Cloudflare Worker, so requests are answered at the Cloudflare location your network reaches first. Its airport-style code appears as "Test server". We do not choose a server inside your provider’s network, which is why results can be lower than tests that do.
What does the test not measure?
Packet loss, which needs UDP; latency to a specific game or service; and speeds beyond what the browser and the device can process, which matters above roughly 1 Gbps. Wi-Fi quality is included in every number, because the test cannot separate it from the line.