How Our Speed Test Works – Testing Methodology

Our principles

Every number comes from a real measurement. Nothing is estimated, simulated or animated to look good.
If we cannot measure something, we say so. A failed test shows an error, not a zero. A metric we could not measure shows "Not measured".
We tell you where the test ran. The location shown is the one Cloudflare reports for the data centre that answered, never a guess.

Where your test data goes

Tests run between your browser and SpeedCheckWeb's measurement service on Cloudflare's global network. Cloudflare automatically routes you to one of its data centres, usually the closest one. The service creates random, incompressible data on the fly for download tests, and reads and discards the data you upload. Test data is never stored.

Your result therefore describes the path between your device and that data centre. It includes your device, your Wi-Fi or cable, your router, your provider's network and the connection between your provider and Cloudflare. It does not directly measure the path to other services, such as a particular game server or video service, which may be further away or connected differently. Tests that use servers inside your provider's own network can show different results. Seewhy speed test results differ.

The test sequence

Connectivity check. The browser contacts the measurement service, reads which Cloudflare data centre answered, and takes three quick latency samples. If the service cannot be reached within 8 seconds, the test stops with an error.
Idle latency. One warm-up request (not counted), then 20 latency samples one after another (30 on the ping test).
Download, with latency samples taken during the transfer.
Upload, with latency samples taken during the transfer.
Packet loss, only when the relay service described below is available.

Latency

Browsers cannot send traditional "ping" (ICMP) messages, so each latency sample is a tiny web request with an empty response, sent over the already-open connection. We time it with the browser's own network timestamps (the Resource Timing API): the time from when the request was sent to when the first byte of the response arrived. This excludes JavaScript processing and connection set-up. If a browser does not provide these timestamps, we time the request with the page clock instead. That includes a little browser overhead, and the result is labelled accordingly.

Reported latency is the median of the samples, the middle value, which a single slow sample cannot distort. Before calculating the median, we ignore extreme high outliers: samples more than three interquartile ranges above the upper quartile (Tukey's fence), which usually come from brief browser pauses. The number of ignored samples is shown in the test details. The response time of our measurement service is included in the figure and is typically well under a millisecond.

Jitter

Jitter is the average absolute difference between consecutive idle latency samples, in the order they were measured. For samples of 20, 30, 25 and 25 ms, the differences are 10, 5 and 0 ms, so jitter is 5 ms. All samples are used, including outliers, because variation is exactly what jitter describes. Different tools define jitter differently, so compare jitter only between tests from the same tool.

Download and upload speed

Real data, counted as it moves. For downloads, the browser counts every chunk of data as it arrives. For uploads, it uses the browser's upload progress reports, and the server confirms receipt of each request. Data is random, so compression cannot inflate the result.
Adaptive requests. The first request is 1 MB (download) or 0.5 MB (upload). Later requests are sized to last about 1.5 seconds at the current speed, or about 8 times the request turnaround time on slow-responding connections. Sizes stay between 0.1 MB and 50 MB (download) or 25 MB (upload).
Parallel requests. Two requests run from the start, with different first sizes so they do not finish at the same moment. While one request is being set up, the other keeps the connection busy. After one second, the test adds parallel requests on faster connections: 3 above 15 Mbps and 4 above 50 Mbps. Browsers may carry these requests over a single shared connection (HTTP/2 or HTTP/3).
When each direction stops. After at least 5 seconds, as soon as the last three one-second speeds agree within about 8%, or after 12 seconds at most, or when the data budget is reached: 400 MB for download and 200 MB for upload, or about 25 MB and 12 MB with Data saver on.
How the final speed is calculated. We ignore a warm-up period at the start: 20% of the test time, at least 1 second, but never more than half the test. That period mostly reflects connection start-up and TCP slow start. The result is the total data transferred after the warm-up, divided by the time after the warm-up. This is an average, not a peak, so short bursts cannot inflate it. Any stalls during that period count against the result, because they are part of how the connection really behaved.
Units. Speeds use decimal megabits per second (1 Mbps = 1,000,000 bits per second) and measure the data your applications actually receive. Network protocol overhead is not counted, so results are slightly below the raw line rate.

If no data at all is transferred in a direction, the test reports an error. It never reports 0 Mbps. A genuine measured speed is always above zero.

Latency under load and bufferbloat

During the download and upload, the test sends a latency sample every 400 ms (250 ms on the ping test), starting one second into each transfer. We report the median of these samples as latency during download andlatency during upload. If a transfer ends too quickly to collect at least 3 samples (this can happen on very fast connections that reach the data budget in a few seconds), that value is shown as "Not measured". Thebufferbloat grade compares the higher of the two with idle latency: under 30 ms extra is Low, 30–100 ms Moderate, 100–300 ms High and over 300 ms Severe. These grade boundaries are our own guidance, not an industry standard.

Packet loss

A normal web request can never show packet loss, because lost data is resent automatically. To measure loss, the test opens a WebRTC data channel set up to behave like UDP (unordered, with no resends) between two endpoints in your browser, and forces it through a TURN relay server. It sends 200 numbered packets of 1,000 bytes (100 with Data saver), 10 ms apart, then waits 2 seconds for late arrivals. Loss is the share of packets that never came back. This describes the path between your device and the relay server.

The relay is a paid Cloudflare service that must be configured by the site operator. When it is not available, or your network blocks it, or your browser does not support WebRTC, the result shows "Not measured" with the reason. It never shows 0%.

Activity verdicts

The "What this connection is good for" verdicts combine your results with published requirements where they exist: Netflix's and YouTube's recommended speeds for HD and 4K, Zoom's bandwidth figures for video calls, and the ITU-T G.114 guidance on voice delay. The latency, jitter and loss thresholds for gaming and calls are rules of thumb. They are listed in our guides, and you should treat them as guidance, not guarantees.

Connection information

Test server location: the Cloudflare data centre code reported for the request, shown with its city where we know it. Unknown codes are shown as the code only.
Your provider and network number (ASN): looked up by Cloudflare from your IP address. This is an estimate, and may show a parent company.
Browser estimate: some browsers report a rough, rounded connection estimate. We label it clearly; it is not a measurement.

Known limitations

Browser tests can under-report very fast connections, roughly above 1 Gbps, because of browser and device processing limits.
Background tabs are slowed down by browsers. If the page was hidden during the test, the result includes a warning.
VPNs, proxies, security software and browser extensions can change results.
Wi-Fi conditions change from second to second, so repeated tests vary. Run several tests and compare.
One test is a snapshot of one moment, on one path, from one device.

Privacy

The measurement service reads your IP address and the network information Cloudflare provides, only to answer your own request. It does not store them. Results are kept only in your browser's local history, which you control. See theprivacy policy for details.

Changes to this methodology

If we change how measurements are made or calculated, we update this page and its date. Questions or suggestions are welcome via our contact page.