How we measure
How we measure
Exactly what our connection test measures, how each number is computed, and what a browser fundamentally cannot measure.
This is the full, canonical methodology (published in English).
Methodology
How we measure, and what we cannot measure
This page exists so you can judge our numbers, and so you can tell the difference between what we know and what we are inferring.
What the test does
- Idle latency (50 samples). We request a small endpoint on our own domain every 60 ms and read the round trip from the browser's PerformanceResourceTiming API. The first five samples are discarded as warm-up.
- Tick-loop phase (20 Hz, 30 s). A WebSocket sends a 12-byte frame 20 times a second, the same rate as a typical shooter server. The server echoes it back verbatim. We record each echo time and count frames that never returned within 2 seconds.
- Loaded latency. We pull a large download in the background while sampling the round trip every 400 ms. The gap between loaded and idle latency is what we call latency under load.
How the statistics are computed
- Percentiles use linear interpolation on the sorted sample set. We report p50, p95 and the maximum, never an average alone — averages hide spikes.
- Jitter is the mean absolute difference between consecutive samples. We also report the 95th percentile of that difference, which is a better detector of intermittent stalls.
- Timeout samples are frames that did not come back within the timeout window. We deliberately call them timeouts, not packet loss: this is a TCP-based transport and TCP retransmits.
- A verdict is only issued when at least 30 usable samples exist. Otherwise the test tells you it does not know.
What a browser cannot measure
| Not measured | Why |
|---|---|
| Your in-game ping | A browser cannot open a raw socket to a game server, and game servers generally do not answer ICMP. Anything claiming to show your in-game ping from a web page is estimating. |
| UDP packet loss | Browsers cannot send raw UDP packets. Our tick-loop test uses a reliable transport, so it detects stalls and timeouts rather than true loss. |
| The route to a game server | Traceroute requires raw ICMP/UDP. Doing it properly needs probes placed in the game's own regions, which is a future version, not this one. |
| FPS, hardware, game netcode | Out of scope by design. A network test that comments on frame rates is guessing. |
| Peer-to-peer and relay-based games | If the game has no fixed server, there is no fixed endpoint to reason about. Matchmaking and relays change per session. |
Where the numbers can be misleading
- Background tabs are throttled by the browser, which inflates intervals. We abort a run when the tab is hidden.
- VPNs and proxies change the path completely, so the result describes the tunnel, not your raw connection.
- Corporate networks often block WebSocket upgrades; we then skip the tick-loop phase and say so.
- A single test point cannot identify which route is bad. That needs several regional probes, and we say so rather than inventing a conclusion.
What we will never write
That a test result is your in-game ping; that any tool "lowers your ping" without measurements; that we verified a product we have not tested. Our reviews include the cases where a product did nothing.