Network / 06

Packet loss soak.

60 HEAD probes to Cloudflare's edge over 24 seconds. Surfaces intermittent loss invisible to a single ping. Anything over 0.5% sustained will degrade calls and games.

Notes

HEAD requests don't directly measure IP-layer packet loss, but they're sensitive to the same path issues — a failed request almost always means lost packets on the way out, the way back, or both.

How it works

We issue 60 fetch(..., { method: "HEAD", cache: "no-store" }) requests to speed.cloudflare.com/__down?bytes=0, one every 400 ms. A successful response counts as 'OK'; any error / abort counts as 'lost'.

Headline is the loss percentage. We also report median RTT across successful probes — useful for sanity-checking that the test path itself isn't degenerate.

Related
Latency
Continuous ping graph for jitter analysis.
Bufferbloat
Latency under saturating load — more common than raw loss.
Speed test
Active download / upload throughput.
Wizard: Pre-meeting check
Auto-runs this plus mic + bandwidth in one flow.
Frequently asked

What's a normal packet loss rate?

On a healthy home connection: 0.0% sustained. Quality wired connections lose nothing for weeks at a time. Cellular and Wi-Fi can show 0.1-0.5% as background noise — usually harmless. Above 1% sustained and you'll feel it: voice calls become choppy, gaming becomes inconsistent, video calls drop.

Why probe 60 times over 24 seconds?

Single-shot ping tools miss bursty loss. A line that loses every 50th packet has 2% loss in aggregate but 0% loss most seconds — you only see it after enough probes to expose the pattern. 60 probes is a reasonable compromise between accuracy and patience.

Where does the loss usually come from?

In order of likelihood: (1) Wi-Fi signal strength — old router, interference, distance. (2) Congested home network (someone backing up to the cloud). (3) ISP last-mile congestion at peak hours. (4) Bad cable or splitter (cable/DSL). (5) Damaged ethernet port or NIC. ISP backbone loss is rare.

Why does the result vary between runs?

Packet loss is genuinely random. Run it 2-3 times to see the actual pattern. If three back-to-back runs all show 0% loss but you still have call quality issues, the problem isn't packet loss — try /network/bufferbloat instead (latency under load is the more common villain).

Can a website really measure packet loss?

Indirectly — we count failed HTTP HEAD requests. True packet loss (at the IP layer) isn't directly visible to JavaScript. But a HEAD request that times out reliably indicates loss on the path, which is what we care about as users.

Related tools in Network
Speed test
Down / up / ping.
Latency
Real-time ping graph.
WebRTC IP leak
Local IPs revealed by WebRTC, VPN check.
Bufferbloat
Latency under saturating load.
Connection type
Wi-Fi / cell, effective rate, save-data.