PulseLAN

Latency first, with the first probe thrown away. A warm-up request pays TCP and TLS setup, and counting it would inflate the idle baseline — which would quietly flatter the bufferbloat grade by making the added latency look smaller. Up to ten probes then follow, with an eight-second cap so a slow link cannot stretch the phase indefinitely — the run detail reports how many actually landed. Ping is the best (minimum) round trip of those, because the minimum is the closest thing to the path’s floor; jitter is the mean absolute difference between consecutive probes, which is the same definition the PulseLAN app uses. Fewer than two probes cannot produce a jitter figure, so in that case it reads “—” rather than a confident 0.

Then throughput, over four parallel streams each way. The first 1.5 seconds of each direction are discarded for TCP slow start, then bytes are counted over a fixed ten-second window. Four streams is the app’s number, kept deliberately: a single Cloudflare stream already saturated a 460 Mbps link during development, so extra streams mostly help slower or higher-latency paths where one connection’s window is the limit — and measuring the browser test at a different concurrency from the app’s would make the two incomparable. Downloads are pulled in chunks sized to about two seconds of the observed rate; uploads are sent with XMLHttpRequest so send progress can be counted as the bytes actually leave, which fetch cannot report.

Latency is sampled throughout, every 300 ms. Each phase reports the median of its samples, not the mean, so one scheduler hiccup cannot decide your grade. The added-latency figure is the worse of the two loaded medians minus the idle median.

The ping shown is an HTTP round trip, and it will read higher than ping in a terminal. A probe is a one-byte request, so the time we measure includes Cloudflare running the code that answers it — roughly 20 ms of their own processing on the runs we tested — plus a few milliseconds of browser and JavaScript scheduling on top. That is not an error, it is what the number is: the time for a real request to be answered. The run detail below the results reports Cloudflare’s own view of the connection’s minimum round trip alongside ours, precisely so the gap is visible rather than hidden. Note that an inflated idle baseline makes the added-latency figure smaller, so it errs toward a kinder grade, never a harsher one.

Nothing here is ever filled in with a zero. A phase that fails shows an error and no number; a metric with too few samples shows “—”. Values under 10 ms are shown with decimals, because rounding a fast link to “0 ms” reads as a broken tool rather than a quick connection.

A browser test measures the browser’s view of the path. Between your network card and this JavaScript sit the browser’s network stack, its HTTP/2 multiplexing, and a tab that shares a CPU with everything else you have open. On a very fast link — multi-gigabit especially — that overhead is real, and a browser will under-report against a native app on the same connection. Treat a low result on a fast line as a floor, not a verdict.

Switching tabs mid-run thins the measurement. Browsers throttle timers in a background tab to about one per second, which cuts how many latency probes land during each phase. Throughput still counts real bytes and stays correct, but the medians behind the grade get built from fewer samples. The run detail always states how many samples each phase actually collected, so you can see when that has happened.

It measures your internet path, not your LAN. Everything on this page is about the route from this device to a Cloudflare edge. It says nothing about how fast this device can talk to your NAS, your desktop, or the laptop in the next room — that is a different link entirely, and measuring it is what the PulseLAN app does. If a file copy at home is slow, this page cannot find it.

We do not name your ISP or your location, because we cannot read them. Cloudflare does not expose that information to a page in your browser, and we are not going to guess at it. The edge code shown in the run detail is a Cloudflare data-centre identifier and nothing more — it is not a city. There are no comparisons to other users on this page either: we have no data on other users, so any such figure would be invented.

One run is one moment. Whatever else was using your connection is part of what you just measured. Run it twice before you conclude anything, and three times before you phone anyone about it.