HTTP latency measures one round trip
Our latency clock starts before a request to this website’s test endpoint and stops after the full valid response arrives. The result includes browser scheduling, network travel and server response time. It is not an ICMP echo to a router, a one-way delay or your game’s server latency.
We show the median completed sample. Illustrative arithmetic: for 20, 22 and 80 ms, the median is 22 ms. With four samples, 20, 22, 30 and 80 ms, the median is (22 + 30) ÷ 2 = 26 ms. A median describes the middle, so it can hide an occasional long delay.
Jitter shows variation
This test uses the mean absolute difference between adjacent successful attempts. For 20, 22 and 80 ms, the differences are 2 and 58 ms; their mean is 30 ms. The example shows why a low median can coexist with inconsistent response.
If an attempt fails, we do not join the samples on either side as though they were consecutive successful attempts. With no adjacent successful pair, jitter is unavailable. Other services may use a different formula or interval; compare definitions before comparing numbers.
Request failures are not raw packet loss
An HTTP timeout can result from a route, server, local software or browser condition. TCP may recover packet losses while the request still succeeds. The HTTP request-failure rate therefore cannot be read as a count of individual lost IP packets.
Illustrative sample: one failure in 24 attempts is 4.17%; one in 100 is 1%. Extra decimal places do not give a small experiment better resolution. Zero observed failures means only that none were observed in that sample.
The current test runs a timed latency phase and displays its actual attempts and failures. It does not always attempt 24 requests. We removed the earlier fixed-count wording and fine loss-rating bands. Read the current method for deadlines and accounting.
Investigate the pattern
- Repeat with the tab visible, noting disconnects and errors. Keep failures in your notes rather than entering zero Mbps.
- Pause backups and uploads, then repeat. A change suggests background traffic is worth investigating; it does not prove a router defect.
- Compare another device and a wired connection under matching conditions.
- Inspect the affected call or game’s own network statistics. Its protocol and destination may differ.
A silent intermediate router in a diagnostic trace does not by itself prove end-to-end packet loss; routers can treat diagnostic traffic differently. Use appropriate end-to-end diagnostics and repeated evidence before assigning a cause.
Definitions and further work
RFC 7680 and RFC 3393 define one-way packet-loss and delay-variation concepts. This HTTP browser test is not an implementation of those one-way metrics. See the request-loss worksheet for more examples and limits.