Why a browser test needs WebRTC
A web page cannot normally send raw UDP. Everything a page fetches travels over HTTP, which runs on TCP or on QUIC, and both resend lost data automatically. A test built on ordinary requests can measure speed and ping, but it can never observe loss, because the transport repairs every gap before the page sees it.
The one way a browser can send unreliable UDP is WebRTC, the technology behind browser video calls. A WebRTC data channel can be configured to be unordered and to never retransmit, which makes it behave like a game or voice stream: a packet the network drops stays dropped. This test uses a data channel configured exactly that way.
Where the packets go
When you press Start, the page asks this site for a set of short-lived credentials for Cloudflare's TURN relay service. The page then opens two WebRTC connections inside your own browser and forces both to use the relay, over UDP only. Each packet leaves your device, travels to the nearest Cloudflare edge, and is relayed straight back to the second connection on your device. Cloudflare runs the relay in hundreds of cities and routes you to the nearest automatically, so the path measured is essentially your own connection: device, wifi, router, line and provider, up to the edge of the internet.
Because both ends of the trip are on your device, the timings use one clock. There is no clock synchronisation to get wrong, and the delay measured for each packet is a true round trip.
What is sent
- 50 packets per second, one every 20 ms, which matches the rhythm of a 20 ms voice stream or a 50-tick game.
- 160 bytes of payload per packet, the size of a standard voice frame. Each carries a sequence number and padding; nothing about you.
- 15, 30 or 60 seconds: 750, 1,500 or 3,000 packets. Roughly 300 KB each way for a 30-second run, so the test does not load the line it is measuring.
- Credentials that expire after five minutes, so the relay cannot be reused after your run.
How each number is calculated
- Packet loss is the percentage of packets sent that did not come back within one second. A packet arriving later than that is counted as lost, because to a call or game it would be.
- Ping is the median round-trip time of the packets that returned. The median is used rather than the average so that one very slow packet does not distort the headline number; the average, minimum, 95th percentile and maximum are shown in the detail panel.
- Jitter is the mean absolute difference in round-trip time between each returned packet and the previous one, in send order.
- Spiky seconds are one-second slices where at least 5% of packets were lost, or where the median ping was more than double the run's median and at least 30 ms above it.
- The verdicts rate the run for each use against thresholds for loss, ping and jitter drawn from ITU-T G.114 for conversational delay, common voice-equipment guidance for loss and jitter, and the ping bands competitive games publish. The worst of the three decides the rating, and the page names which one it was.
Limits
The test measures your connection to the nearest Cloudflare edge. It cannot see loss on the route from there to a particular game server or call bridge, and it cannot separate loss on the way out from loss on the way back, since each packet does both. It also depends on the browser keeping to time: if the tab is moved to the background, browsers slow their timers, so the test stops rather than report false loss. The calculation code is a small, separately tested module; the thresholds are listed on the acceptable packet loss page.