Ping Test

How to use this, and how to read the result

1. The quick test runs on its own. Twenty-five timed round trips take a few seconds and fill in every figure above. Two extra warm-up probes run first and are thrown away, because the first request after an idle moment may have to rebuild the TCP and TLS connection and would read tens of milliseconds high.
2. Read the median, not the mean. The median is the middle sample: one unlucky 400 ms outlier moves it barely at all, while it drags the mean somewhere no packet actually went. When the two disagree badly, the mean is telling you there is a tail.
3. Read the spread, not just the middle. min is what the line does when nothing is in the way — that is your physical floor. p95 is what one packet in twenty actually experiences. A wide gap between them is exactly what makes a game feel inconsistent while the average looks perfectly healthy.
4. Check jitter. Jitter here is the mean absolute difference between one sample and the next one after it, skipping any pair that has an unanswered probe between them — a gap of several seconds is not packet-to-packet variation and would not be honest to count as it. Voice chat and game netcode both budget for a steady delay and cope badly with a delay that changes on every packet, which is why 60 ms of rock-steady latency beats 30 ms that keeps moving.
5. Then run the 60-second stability test. That is the one that answers why does my game lag sometimes. A five-second test cannot see a spike that happens once a minute, and once a minute is enough to lose a fight.
6. Read the verdict, not only the grade. Periodic spikes, sustained degradation and failed requests are listed separately on purpose: they have different causes and completely different fixes, and a single letter cannot tell them apart.

What is actually being measured

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, the size of the tail, 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 one 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 here waits for the previous one to finish before the next is sent. 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 and 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 on this page are therefore 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.

Reading the shape of the distribution

The histogram is doing more work than the headline number. Averages hide exactly the behaviour that ruins games and calls, and the shape does not.

• One tight cluster. Everything piled into two or three adjacent buckets is a healthy line. The path is stable, nothing is queueing, and whatever the median says is genuinely what every packet gets.
• A long tail to the right. A solid cluster with a thin smear running out to two or five times the median is the signature of queueing — either buffer bloat on your own connection or congestion somewhere upstream. If it appears only while something is uploading or downloading, it is yours to fix. If it is there on an idle line, it is upstream and out of your hands.
• Regular spikes at even intervals. Almost always Wi-Fi. The stability test measures the gaps between spikes precisely because a radio problem repeats on a clock and congestion does not.
• Two separate clusters. Two humps thirty or more milliseconds apart normally means two paths. Common causes: a laptop drifting between two access points, a phone handing between Wi-Fi and mobile data, or a VPN that only some connections go through.
• A staircase that climbs and stays. If the last third of a run sits well above the first third and never comes back, something started while you were measuring — a game updating, a cloud sync waking up, a backup, or another device on the network. This is called out separately as sustained degradation because the fix is to find the culprit, not to change the router.

Why more Mbps does not fix lag

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.

What actually sets your latency, in rough order of how much it matters:

• Distance. Light in fibre covers about 200,000 km per second, so a round trip costs roughly 1 ms per 100 km even in a perfect world. A server 2,000 km away cannot be faster than about 20 ms, ever, and real routing is never the straight line on the map. This is the floor, and no product fixes it — you pick a closer server instead.
• The last mile technology. Fibre adds a millisecond or two. Cable adds a few more. DSL adds more again. 4G typically adds 30 to 50 ms, 5G rather less. Satellite is in a category of its own: a geostationary link has a hard physical floor near 480 ms — four trips through 35,786 km of vacuum — and lands closer to 600 ms in practice, while low-earth-orbit services land around 25 to 60 ms with visible variance as satellites hand over.
• Wi-Fi. On a good 5 GHz link, a couple of milliseconds. On a congested 2.4 GHz channel with retries, anything from 5 ms to well over 100 ms, arriving unpredictably. This is the biggest single thing most people can actually change.
• Queueing on your own line. Buffer bloat, below. This is the one that makes latency triple the moment somebody starts an upload.

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 that 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.

Latency to a CDN edge is not latency to a game server

The chip under the headline number 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: 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.

What to do about a bad result

1. High median, low jitter, no spikes. That is distance and last-mile technology, not a fault. Nothing on your side will fix it; pick servers in a closer region and confirm which edge answered above.
2. Low median, high jitter, regular spikes. Wi-Fi, with high confidence. Plug in a cable and re-run the test. If the spikes vanish, you have your answer in under a minute.
3. Fine when idle, terrible under load. Buffer bloat. Enable SQM or QoS on the router and shape to slightly under your real line speed.
4. Latency climbs and stays climbed. Something started competing for the line. Check for game and OS updates, cloud sync, backups, a TV streaming in another room, and anything on a schedule.
5. Failed probes. Something is dropping out rather than slowing down. Test on a cable to rule out radio, then check for a failing cable or port, an overheating router, DNS problems, or an ISP fault worth reporting — a stability run with a failure count is exactly the evidence support desks ask for.
6. Everything is good here but the game still lags. Then the problem is past your connection: the route to that server, the server itself, or that specific game. Run the test again during the bad period; a connection that is clean while the game stutters is genuinely useful information.

Related tools