What this website counts
The website's latency stage attempts 24 uncached HTTP requests. The displayed loss result is the number of failed or timed-out requests divided by the number of attempts. HTTP requests travel through browser, transport, network and server layers. A failure may involve connectivity, server response time, a timeout or local software; it is not a direct count of lost packets.
The current self-hosted test endpoint is /api/network on this website. Its response time includes the route to the hosting service and server processing. It should not be described as guaranteed nearest-edge latency, nor as latency to your game or meeting server. See the methodology for the other metric definitions.
Why a single failure makes a large percentage
With only 24 attempts, the resolution is coarse: one failure is 100 ÷ 24, or about 4.17 percentage points. Two failures are about 8.33%. Reporting more decimal places does not create a more precise experiment.
| Failed requests | Observed request loss | Interpretation |
|---|---|---|
| 0 / 24 | 0% | No request failure observed in this short sample |
| 1 / 24 | 4.17% | One request failed or exceeded its deadline |
| 2 / 24 | 8.33% | Two requests failed or exceeded their deadlines |
Zero out of 24 does not establish that the connection never drops packets. Conversely, one failure does not establish that 4.17% of the network's IP packets are being lost. The measurement unit is different.
Ping and jitter answer different questions
The site's ping value is the median completed request round-trip time. Jitter is the mean absolute difference between consecutive latency samples. A low median can coexist with occasional delays; the median does not describe the slowest event.
Illustrative arithmetic: latency samples of 20, 22 and 80 ms have a median of 22 ms. Their consecutive differences are 2 and 58 ms, so the mean absolute difference is 30 ms. The typical delay and the variability tell different parts of the story. These three invented values demonstrate the formula, not a real connection's performance.
Different tools use different jitter definitions, sampling intervals and protocols. Compare the definition before comparing the number. Our HTTP timing is not an implementation of the IETF's one-way IP measurement protocols.
What to do when a result looks bad
- Repeat once with this tab visible, noting any disconnect or browser error.
- Check whether another device has the same symptom. A single-device failure is a reason to inspect that device, not proof of a line fault.
- If possible, compare wired and wireless under matching conditions.
- Check the affected application's own connection statistics. A call can use a different destination and protocol.
- Keep the failed attempt in your log. Share repeated patterns with support rather than a single isolated percentage.
A short browser result cannot locate a failing network hop. Do not interpret intermediate-router ping silence as proof of packet loss without an appropriate end-to-end diagnostic: routers can treat diagnostic traffic differently from forwarded traffic.
Measurement references
The IETF distinguishes a packet-loss measurement by its packet type, path and timing parameters. RFC 7680 is the updated one-way loss reference. RFC 3393 explains IP packet delay variation. These references explain the distinction; they do not certify this website or its ratings.