Speed Test
Measure your current connection latency, jitter and throughput against a Cloudflare-scale edge. No browser plugins, no tracking.
Measures your connection to the nearest Cloudflare edge. The test transfers real data, so it needs a few seconds and some bandwidth.
About the speed test
Measures your current connection to Cloudflare's edge: idle latency and jitter, download and upload throughput, and latency under load. Runs entirely in your browser with fetch(), no plugin, no app.
A run takes about 20 seconds: a warm-up plus 20 latency probes, then up to ten seconds of downloads with growing file sizes and four parallel streams, then up to eight seconds of uploads with three parallel streams. Throughput is the 90th percentile of steady-state samples, the way Cloudflare's own test reports it, so a slow first second does not drag the result down. During both transfer phases small probes keep measuring latency, which reveals bufferbloat.
Interpreting the numbers
- RTT - time for a tiny request to reach the edge and back. Below 30 ms feels instant; above 100 ms is noticeable for interactive work.
- Jitter - variability of RTT. High jitter hurts VoIP and gaming more than it hurts browsing.
- Download - throughput for a few large parallel transfers. Most home connections peak below the advertised number because of TCP overhead and WiFi.
- Upload - critical for video calls, backup and file sharing. Often much lower than download on asymmetric connections.
- Loaded latency - RTT measured while the download or upload saturates the line. A jump of more than 100 ms over idle latency means bufferbloat: calls and games stutter whenever someone in the household transfers data.
How it works
A speed test answers four different questions, and each one is measured differently. Latency is the time a very small request needs to travel to the test server and back. Jitter describes how much that time fluctuates from one request to the next. Download and upload throughput describe how many bits per second the connection can carry in each direction once a transfer is under way.
Latency and jitter
The test first sends one warm-up request and then 20 small requests with an empty response body. For each request the browser's timing data is used to take the span between sending the request and receiving the first byte of the response, minus the time the server reports for its own processing. The idle latency shown is the median of these 20 samples, which makes a single outlier harmless. Jitter is the average absolute difference between consecutive samples, so a line that alternates between 20 ms and 40 ms shows a jitter of about 20 ms even though its median looks fine.
Download and upload
For the download phase the browser requests files of increasing size over several parallel streams, starting small so that a slow line does not stall the test. Received bytes are summed in windows of roughly 150 ms, and each window yields one throughput sample in Mbit/s. The first few windows are discarded because TCP is still ramping up, and the reported value is the 90th percentile of the remaining samples. The upload phase works the same way, except that the browser posts blocks of data and counts the bytes the network stack reports as sent. Both phases are time-limited, which is why the amount of data transferred depends on how fast your line is.
Loaded latency
While the download and the upload run, a small latency probe is repeated about every 400 ms. The median of these probes is the loaded latency. Comparing it with the idle value shows how much queueing delay builds up in routers and modems when the line is full.
How to read the results
- Download and Upload are shown in megabits per second (Mbit/s). File sizes in browsers and operating systems are usually shown in megabytes (MB). Divide a Mbit/s value by 8 to get MB/s, so 100 Mbit/s corresponds to roughly 12.5 MB/s at best.
- Latency is the idle median to the nearest test server. It measures the path to that server, not to every service you use, so a video call platform in another region can still have a higher round-trip time.
- Jitter is the average change between consecutive latency samples. Low jitter matters for real-time audio and video, where packets that arrive unevenly cause gaps or robotic sound.
- Loaded latency is shown as two values, while downloading and while uploading. A large difference to the idle latency indicates bufferbloat.
- Test server is the edge location that answered. A server far from you raises latency but usually has little effect on throughput.
Common pitfalls
- WiFi against cable: wireless throughput depends on distance, walls, channel congestion and the device's own radio. Test once over a cable to learn what the line itself delivers, then compare with WiFi in the room where the problem occurs.
- VPN and proxies: traffic takes a detour through the VPN endpoint, which adds latency and often caps throughput. Disable the VPN for a baseline measurement.
- Time of day: shared access networks are busier in the evening. Run the test at different times before drawing conclusions from a single result.
- Other devices and tabs: streams, backups, cloud sync and updates compete for the same line. Close them or pause them during a run.
- Browser limits: a browser test cannot reach the full capacity of very fast lines because a single tab, the CPU and the network card all limit it. Treat the result as a lower bound on very fast connections.
- Overhead: the value you see is usable payload throughput. Protocol headers and encryption mean it is normally somewhat below the speed in your contract.
Examples
Download is high, but video calls stutter
A result of 300 Mbit/s down and 20 Mbit/s up looks generous, yet calls drop out. Look at jitter and loaded latency instead. If jitter is above roughly 15 to 20 ms or the loaded latency is far above the idle value, the connection is fast but inconsistent. Typical causes are WiFi interference and a router that queues too much data. Switching to a cable or enabling smart queue management on the router often helps more than a faster plan.
Download is much lower than the contract
You pay for 500 Mbit/s but see 90 Mbit/s. Repeat the test with a laptop connected by cable, with the VPN off and other devices idle. If the cabled result reaches the expected range, the limit is your WiFi. If it stays low on a cable at several times of day, the problem is in the router, the cable or the access line, and the cabled result is useful evidence when you contact your provider.
Upload is very low
Download of 100 Mbit/s with 3 Mbit/s upload is normal for asymmetric connections. It becomes a problem when you send large files, run backups or present in video calls with several participants. In that case compare the upload figure with the bitrate your application needs, and check whether a backup or sync client is using the upload at the same time.
Common problems and how to fix them
- Results vary widely between runs: other traffic or an unstable WiFi link is the usual reason. Run the test three times and compare the median, not the best value.
- High idle latency: check for a VPN, a distant test server, a congested WiFi channel or a router under heavy load. A restart of the router and a cabled test narrow it down quickly.
- Large increase under load: this is bufferbloat. Enable traffic shaping or queue management on the router if it offers it, and limit the configured rate slightly below the measured line speed.
- Test fails or stops early: browser extensions that block network requests, strict firewalls or a lost connection can interrupt it. Try a private window without extensions.
- Upload is much lower than expected: check for running backups, cloud sync or a device that is uploading in the background.