Find packet-loss signals from the browser: request timeouts plus server-side TCP retransmission, with clear notes on what a browser can and cannot see.
Runs in your browser
Quick mode uses about 8 MB; Full uses about 30 MB. The main signal is server-side retransmission, not a guessed “packet loss” percentage.
What this measures
A browser cannot count raw IP packet loss directly. This page shows the two signals it can see: request timeouts and Cloudflare’s downstream TCP retransmissions.
7.63 MB
Timeouts use a stricter 1 s deadline because a one-second-late packet is already useless to real-time traffic.
Why a browser cannot show a true packet-loss ratio
Browsers do not send raw IP packets, so they cannot count how many disappeared in flight. Any site that presents a precise browser-side packet loss percentage is measuring a proxy and naming it more strongly than it should.
Why retransmission is the main signal here
TCP hides a lot of loss by resending missing segments before your browser notices. That is exactly why the retransmission row matters: it reveals repairs that a simple timeout count would miss.
What to check first when both rows are bad
Test again on a cable. If the problem shrinks, the wireless link was part of it.
Restart the modem and router, then repeat the test at another time of day.
How to use
Run the timeout probe to see whether requests miss a one-second deadline.
Read the retransmission row next. That is the signal most speed tests hide.
Use the diagnosis and the use-case verdicts together before blaming the ISP or the game server.
FAQ
Why does the page avoid the phrase “packet loss rate”?
Because the browser is not measuring IP-layer loss directly. The labels stay honest about what was really observed.
Why can retransmission be non-zero while timeouts stay at zero?
Because TCP often repairs missing data fast enough that the request still finishes on time. The retransmission row catches that hidden work.