The measurement engine
The test uses @cloudflare/speedtest, Cloudflare’s open-source JavaScript measurement engine (MIT licensed), the same engine behind speed.cloudflare.com. It runs entirely in your browser. We configure which measurements it runs and in what order, and we present the results. We don’t alter the engine’s calculations.
The engine is only downloaded when you start a test, so it doesn’t slow down pages for people who are only reading.
Test servers
All download, upload and latency requests go to Cloudflare’s global network at speed.cloudflare.com. Cloudflare uses anycast routing, so your request is answered by a nearby Cloudflare data center chosen by normal internet routing. We don’t pick or display a specific server, and we don’t show a server location we can’t verify.
Because the server is usually close to you, results show what your connection can do over a short path. Services hosted far away, such as a game server in another region, will see higher latency.
Test sequence
- Initial latency: one tiny request, plus a 100 KB download to warm up the connection.
- Idle latency and jitter: 20 more tiny requests while nothing else is running.
- Download: requests of 100 KB, 1 MB, 10 MB, 25 MB, 100 MB and 250 MB, several of each.
- Upload: 100 KB, 1 MB, 10 MB, 25 MB and 50 MB, several of each.
- Packet loss: 1,000 UDP packets through a TURN relay.
Larger sizes are only used when needed. Once requests in one direction take longer than about one second, the engine stops stepping up in that direction. Slow connections finish sooner and use less data; fast ones get large enough transfers to reach full speed.
How download speed is measured
For each download request, the browser’s Resource Timing API records when the response started and finished. The engine divides the bits transferred by the transfer time, subtracting the time the server reports spending on the request. Requests shorter than 10 ms are ignored as too short to be reliable.
The reported download speed is the 90th percentile of the remaining measurements. In plain terms: the speed your connection reached or exceeded on the best tenth of transfers, which reflects what it can sustain while discounting the slow start of small requests.
How upload speed is measured
Upload works the same way in reverse. The browser sends blocks of data of increasing size, the time for each is measured, and the result is the 90th percentile of the measurements.
How ping (latency) is measured
Latency requests ask for zero bytes, so the time is almost entirely delay. The engine measures from when the request is sent to when the first byte of the response arrives, subtracts the server’s own processing time, and reports the median of 21 idle samples.
During the download and upload phases, the engine also sends a small latency request about every 400 ms. These loaded latency results appear under “Test details” and on the bufferbloat test. They show how much delay builds up when your connection is busy.
How jitter is measured
Jitter is the average absolute difference between consecutive idle latency samples. It shows how much delay varies from one moment to the next. This is similar in purpose to, but not the same calculation as, the interarrival jitter that call apps compute from their own packets (RFC 3550).
How packet loss is measured
Web requests use TCP, which resends lost data and hides loss. To measure loss directly, the engine opens a WebRTC data channel over UDP through a TURN relay on Cloudflare’s network. Your browser sends 1,000 numbered messages in batches of 10, routed through the relay back to itself, then waits three seconds for late arrivals. Packet loss is the share that never came back.
Access to the relay uses short-lived credentials. Our site requests them from Cloudflare’s Realtime TURN service through a small server function on this website, so no secret keys are exposed in the page.
How the result summary is produced
The summary under your result compares your numbers with published requirements: 5 Mbps per Full HD stream and 15–20 Mbps per 4K stream (Netflix, YouTube), video call bandwidth from Zoom and Microsoft, and Microsoft’s Teams targets for latency, jitter and packet loss. For gaming, where game makers don’t publish common figures, we use widely used guidelines (for example, ping under 50 ms and jitter under 15 ms for a “should work well” verdict).
The summary uses plain labels such as “Should work well”, “May be limited” and “Likely to struggle”. We don’t produce an overall score or grade, because a single score hides what matters for different uses.
Limitations
No speed test is perfectly accurate, and ours is no exception. Results are affected by:
- Your device and browser. Older processors, busy browsers and extensions can limit very high speeds.
- WiFi. A WiFi result measures your wireless link as much as your internet plan.
- Other traffic on your network during the test.
- Network conditions on your provider’s network and between it and Cloudflare, which change through the day.
- Server distance and routing. We test to a nearby location; distant services will perform differently.
- VPNs, proxies and security software, which add steps and processing.
- Very fast connections. Above a few Gbps, a browser may not be able to measure the full speed. Treat such results as a lower bound.
- Provider traffic handling. Some networks treat speed test traffic or certain protocols differently from other traffic.
Different speed tests use different servers, file sizes and calculations, so they can give different results on the same connection. That doesn’t mean one is wrong; they are measuring slightly different things.
How to get the most reliable measurement
- Use a wired connection for a baseline.
- Pause other devices and close other apps.
- Turn off VPNs unless you want to measure them.
- Run several tests and look at the typical result.
- Test at different times of day.
The full method is in how to test your internet speed.
Changes to this methodology
Read more about the project and our disclaimer on the limits of results.
If we change the engine version, the measurement sequence or the way results are summarized, we will update this page and its date.