Internet Speed Test

The useful part is that the overhead is roughly constant. It sits underneath every sample equally, so it shifts the whole distribution a little to the right and leaves its shape untouched. Everything this page cares about most, jitter and the size of the tail and whether spikes arrive on a clock, is a statement about the differences between samples, and those differences survive the overhead intact.

Probes are sent one at a time, never in parallel. Fire ten requests at once and they queue on the same connection; the tenth waits for the nine in front of it and reports that queue as latency. It would look like a network problem you do not have. Each probe waits for the previous one to finish. The quick test then leaves a fixed 130 ms gap; the stability test instead places each probe on a 250 ms grid measured from the moment the run started, so a slow probe does not push every later one further behind and the spike-interval maths stays meaningful.

The clock is not infinitely fine, so the numbers are not printed as if it were. Browsers deliberately coarsen performance.now() to blunt timing attacks, roughly 100 microseconds in Chromium and a full millisecond in Firefox and Safari. Figures here are shown to one decimal place below 100 ms and to the nearest millisecond above it. Averaging many samples does genuinely recover some resolution below the clock's step, which is why the median and jitter are still worth a decimal, but a second one would be decoration.

Nothing is served from a cache. This site installs a service worker that answers same-origin GET requests from Cache Storage. If the probes were plain GETs they would be answered from your own disk in well under a millisecond and the page would confidently report a fantasy. Two things prevent that: the probe is a HEAD, which the service worker deliberately ignores, and the request is issued with cache: no-store so the browser's own HTTP cache cannot answer either. If a fallback path ever has to use GET, it carries a unique query string and a Range header so the response is a 206, which the Cache API is required by spec to refuse to store.

A failed probe is not the same as a lost packet. TCP retransmits lost packets invisibly, so a single dropped packet normally shows up here as one slow sample rather than a failure. A probe only counts as failed when nothing came back at all, or, on a request the network refuses outright, as soon as it is refused. The waiting limit is six seconds until five samples exist and nothing about your line is known yet; after that it becomes twelve times your own median, floored at two seconds and still capped at six. Scaling it matters: a fixed six seconds would let a line that dies part-way through a sixty-second run burn a tenth of the run on a single dead probe, and it would let a 200 ms dropout on a 15 ms line masquerade as a healthy sample. If nothing answers at all from the start, the run gives up after three silent probes rather than making you sit through the rest of it. The consequence is that the failed figure is a far harsher signal than a packet-loss percentage from a native tool: one failure in sixty is already worth investigating, and it usually means a link is dropping out rather than merely dropping packets.

Upload is not measured, and here is why. Measuring upload needs a server that will accept a POST and read the whole body. Vorla is static hosting, so it answers a POST with an error and there is nothing to time. The download test sends an 8 KB probe to a URL that does not exist, purely to find out whether this host would accept a POST at all, and then tells you it failed rather than inventing a number.

This is the single most expensive misunderstanding in home networking, and ISPs are not in a hurry to correct it. Bandwidth is how much fits down the pipe each second. Latency is how long one thing takes to get there and come back. They are close to independent. A competitive shooter sends packets of a couple of hundred bytes, sixty or more times a second, on the order of a hundred kilobits per second in total. It has never once been limited by your 500 Mbps line, and upgrading to 1000 will change precisely nothing about how it feels.

Loading a page means a DNS lookup, a TCP handshake, a TLS handshake and then the request: four or more round trips before the first byte of content. At 15 ms that is invisible. At 150 ms the same page feels sluggish on a gigabit line, because the delay is in the waiting, not the transferring. Going from 50 to 500 Mbps changes nothing about that; halving the latency changes everything.

Jitter deserves its own paragraph because it hurts more than raw latency and gets far less attention. Voice chat and game netcode both handle a constant delay gracefully: the client predicts, the codec buffers, and everything feels fine. Neither handles a delay that changes packet to packet. A voice application responds by growing its de-jitter buffer, which adds latency to absorb the variance, so high jitter turns into audible delay and then into the chopping everyone recognises. Game netcode responds by mispredicting, which is the rubber-banding you feel as lag even though the average ping never moved.

And then there is the cable. A wired connection resolves more lag complaints than any other single change, by a wide margin. Wi-Fi is a shared radio: only one device on a channel transmits at a time, everything retries when a frame collides, power saving parks the radio between packets to save battery, and the access point periodically stops serving you to scan other channels. Every one of those is a spike, and none of them exists on Ethernet. If a cable is genuinely impossible, the ranked next-best options are: move to 5 GHz or 6 GHz, pick a clear channel, move closer to the access point, and turn off Wi-Fi power saving on the client. Powerline adapters and mesh nodes with no wired backhaul both usually make jitter worse, not better.

The chip under the round-trip readout shows which Cloudflare datacentre answered your probes, read from /cdn-cgi/trace on this site. The three-letter code is an IATA airport code for the building. A large CDN runs hundreds of these and steers you to a nearby one, which is why a good result here can be in single-digit milliseconds: you may be measuring a round trip to a rack a few kilometres away.

Your game server is not in that rack. It is in whichever region the publisher chose, it is reached over paths a CDN has spent a fortune optimising and your game has not, and it is doing real work before it answers. So expect your in-game ping to be higher than the number on this page, often much higher, and treat this figure as the floor your connection is capable of rather than a prediction. What transfers cleanly between the two is everything about consistency: if this page shows 8 ms of jitter and spikes every twelve seconds, your game is getting the same treatment, whatever its absolute ping happens to be.

If you need the actual latency to a specific game server, a browser cannot get it for you and no browser tool honestly can. The server is on a different origin with no CORS headers you may use, most game servers speak UDP rather than HTTP, and many do not answer ICMP at all. Use the in-game network overlay if there is one, or a native tool: ping and tracert on Windows, ping and mtr on Linux and macOS. mtr is the one worth learning, because it pings every hop on the path continuously, so you can see which router the loss or the delay starts at instead of only that it exists somewhere.