How fast is your internet, really?
One tap. 8 parallel streams to the nearest Cloudflare edge measure your true download, upload, ping, jitter — and the bufferbloat most speed tests never show you.
Get a reading you can trust
Four steps field engineers use before blaming the ISP.
Ethernet or 5 GHz
Cable in, or stand close to the router on 5 GHz — 2.4 GHz Wi-Fi tops out around 50–100 Mbps and hides your real speed.
Stop other traffic
Pause downloads, cloud backups, streams and other devices so the test gets the full line.
Run it 3 times
Test at different hours — fast mornings but slow 9 PM points to peak-hour congestion, not a fault.
Compare vs plan
Above 90% of plan = healthy. Below 70% on Ethernet = raise a ticket — your history here is the evidence.
Did you beat your plan?
Enter the speed your ISP sold you. We'll show how much of it you're actually getting.
Run the test first, then see how your real speed compares.
Under the hood
Latency under load — the number that ruins video calls
A connection that pings 10 ms when idle can ping 400 ms while downloading — that's bufferbloat. We measure it live during both transfer phases:
Grades follow the Waveform scale on the added latency: A+ <5 ms · A <30 · B <60 · C <200 · D <400 · F ≥400. If you score C or worse, enable SQM / fq_codel on your router.
Throughput over time
■ download ■ upload — each point is a 100 ms sample summed across all parallel streams. A flat line means a stable link; sawtooth means Wi-Fi interference or congestion.
Methodology — why this test is accurate
- Nearest server, always: tests run against the closest of Cloudflare's 300+ edge locations, so you measure your access network — not a distant server's backbone.
- 8 download / 6 upload parallel streams saturate the link the way real traffic does, defeating single-stream TCP window limits.
- Streaming byte counters: throughput is sampled every 100 ms from the raw byte stream — not per-request — so connection setup time never skews the number.
- Ramp-up discarded: the TCP slow-start period is excluded; the reported figure is the trimmed mean of the sustained window.
- Server time subtracted: ping uses the Server-Timing header to remove server processing time from each sample; latency is the minimum of 12 samples, jitter the mean successive difference (RFC 3550).
- Adaptive finish: once throughput is stable (<8% variation for 3 s), the phase ends early — accurate and fast.
Why is my speed lower than my plan?
Field-engineer answers — the six causes behind 90% of "slow fiber" complaints.
Wi-Fi bottleneck
The #1 cause. 2.4 GHz Wi-Fi tops out around 50–100 Mbps in practice. Test on Ethernet or 5 GHz close to the router before blaming your ISP.
100 Mbps port or NIC
An old laptop NIC or a Fast-Ethernet router port caps you at ~94 Mbps forever. Adapter settings must show 1000 Mbps Full Duplex.
Bufferbloat
Oversized router buffers queue packets under load — ping explodes from 10 ms to 400 ms. Fix with SQM (fq_codel / CAKE) set to ~90% of line rate.
GPON asymmetry
GPON is 2.5 Gbps down / 1.25 Gbps up shared across up to 32 homes. Slow uploads and peak-hour dips are architecture, not a fault.
Peak-hour congestion
Fast at 6 AM, slow at 9 PM? That's an oversubscribed PON port or backhaul. Log results here at different hours — the history table is your evidence for the ISP ticket.
Double NAT
ONT in router mode + your own router = two NAT layers, broken port-forwarding and extra latency. Put the ONT in bridge mode.