Services Tools What is my IP Cable map Resources Request assessment

Internet speed test

Measures latency, jitter, and throughput from this browser to the nearest edge server. Latency and jitter are the numbers that actually predict whether video calls and cloud apps hold up — throughput alone rarely explains a bad connection.

Ready
—
press start
latency
—
jitter
—
download
—
upload
—

How to read these numbers

Latency

Round-trip time to the server, reported as the lowest clean measurement rather than an average — the minimum is closer to the true path delay, since averages get dragged upward by one-off scheduling hiccups. Under 30 ms is excellent, under 60 ms is fine for anything, and above 150 ms starts to be noticeable in conversation on a video call.

Jitter

How much the latency varies between consecutive measurements. This is the most under-appreciated number on the page. A connection with 40 ms latency and 3 ms jitter will carry a video call cleanly; the same 40 ms with 40 ms of jitter will sound choppy, because voice and video packets arrive unevenly and the receiver has to either wait or drop them. If calls are bad but the speed number looks fine, jitter is usually the reason.

Download and upload

Throughput in megabits per second, measured with several parallel connections. Upload matters more than most people expect — your camera feed on every video call goes up, not down, and a connection sold as "500 Mbps" is often 500 down and 20 up.

This will read lower than Ookla or fast.com, and on a gigabit line it will read a lot lower. The reason is physics, not a bug. At 1 Gbps with 45 ms of latency you need roughly 5.7 MB of data in flight at any instant just to keep the pipe full, and TCP takes several round trips to ramp up to that. A browser test that moves tens of megabytes finishes before the ramp completes, so it measures the ramp. This test discards its opening window and runs six parallel connections to reduce that effect, but it still caps how much data it will pull, and a single serverless endpoint is not a speed-test server. Treat this as a latency and jitter measurement with a throughput estimate attached — not as verification of a contracted speed. To actually confirm a gigabit line, use iperf3 against a nearby server, or your provider's own wired test.

What a browser test cannot see

Wi-Fi is the single most common bottleneck and it hides here — a test over Wi-Fi measures your wireless link as much as your internet connection. Retest wired before concluding anything about the circuit itself. This also cannot see packet loss under load, buffer bloat, or which of several hops is degrading, all of which need testing from the network rather than from a browser tab.

One thing it can tell you: if the download figure comes back above about 95 Mbps, your cabling and switch port are negotiating faster than 100 Mbps, because that is the hard ceiling for application traffic on a 100BASE-TX link. A result pinned just under 95 Mbps on a connection sold as faster is worth investigating — a damaged cable with only two usable pairs, or a port that negotiated down, will do exactly that.

Numbers look wrong for what you pay?

Slow links often trace back to a misconfigured circuit, an oversubscribed uplink, or a contract that quietly renewed at the wrong speed. That is worth looking at properly.

Request an assessment