Ping & Packet Loss Test

How it works

1. Close Other Downloads and Streams. Another device or app pulling bandwidth during the test will inflate the latency-under-load number for reasons that have nothing to do with your connection's actual behavior.
2. Prefer Ethernet, or Sit Close to the Router. Wi-Fi adds its own latency and jitter on top of whatever your internet line does — a cable isolates the measurement to the line itself.
3. Press Start and Leave the Tab in the Foreground. Browsers throttle background tabs, which would silently corrupt the timing this test depends on.
4. Watch Idle Latency First, Then Latency Under Load. The first phase measures your connection at rest; the second starts a download alongside the same latency probes to see how much it slows down while busy.
5. Read the Stability Counters, Not a Loss Percentage. There isn't one — see below for why — but the number of probes that never got a reply, and how many came back unusually slow, tells you almost the same thing.
6. Run It Again During Peak Hours. Latency and bufferbloat are more sensitive to time of day than raw speed is — an evening result can look meaningfully different from an afternoon one.

What This Test Actually Measures (and Why "Ping" Is a Slight Misnomer Here)

The `ping` command sends a raw ICMP packet and times the reply. A web page cannot do that — browsers have no access to ICMP or to raw sockets of any kind, for the same sandboxing reasons a web page can't read your files without asking. So this test does the closest honest thing available: it times an ordinary HTTPS request to Cloudflare's network and subtracts the server's own reported processing time, leaving just the network round trip.

• It's a real, measured round trip — not a simulation or an estimate, just over HTTPS instead of ICMP.
• It typically reads a few milliseconds higher than a terminal ping to the same destination, because a TLS-secured HTTP exchange still costs a little more than a bare ICMP echo, even after subtracting server processing time.
• It measures the path to a Cloudflare edge location, not to any specific game server, call provider, or website — treat it as a proxy for "how good is my connection, generally," not as the exact number you'd get to any one destination.

Why There's No Packet Loss Percentage on This Page

This is worth explaining plainly rather than just omitting the number, because its absence is a deliberate choice, not a missing feature.

• TCP — the protocol underneath every ordinary web request — retransmits lost data automatically and invisibly. A packet that gets lost doesn't fail; it just arrives late, after one retry.
• That means a web page timing HTTP requests literally cannot see a lost packet as loss — it sees a slow reply, indistinguishable at a glance from ordinary congestion.
• A tool that computed "0% packet loss" from that data wouldn't be reporting a low loss rate — it would be reporting that it couldn't detect loss at all, which is a very different thing to tell someone troubleshooting a flaky connection.
• Real packet loss measurement needs a protocol that doesn't hide the loss — raw ICMP or UDP — which is exactly what a browser is not allowed to send.

What this test reports instead: how many latency probes got no reply at all within a generous timeout, and how many came back much slower than the typical probe on your connection — a signal that a retransmit likely happened, even though it can't be counted directly. Neither number is loss. Both are the closest evidence a browser can actually gather.

Latency, Jitter, and the Worst Case: What Each Number Means

The test reports three related but distinct numbers from its idle-latency phase.

• Latency (ms): the typical round-trip time — technically the median of all probes, which resists being skewed by one slow outlier the way an average would be.
• Jitter (ms): how much that round trip varies from one probe to the next, not how high it is on average. A connection can have decent average latency and still feel choppy on a call if jitter is high.
• Worst case (ms): the 95th-percentile round trip — close to the number you'd actually notice in a call or a game, since a single very slow moment stands out far more than the typical one.

Bufferbloat: Why Your Connection Gets Laggy the Moment a Download Starts

This is the number most speed tests skip entirely, and it's often the actual explanation for "my connection is fine until someone else starts downloading something."

• Most routers and modems queue outgoing data in a buffer before sending it — a reasonable idea that goes wrong when that buffer is oversized for the connection.
• When a big download or upload fills that buffer, every other packet — including this test's latency probes, and every packet from a call or game — has to wait in line behind it.
• The result: latency that's fine when the connection is idle can jump from 20ms to 300ms or more the instant something starts saturating the line, then drop back down when it finishes.
• This test measures exactly that: it runs a saturating download in the background while continuing to send latency probes, then compares the latency before and during.

Grades run A+ through F, based on how much the latency increases under load — A+ is a barely-noticeable few milliseconds, F is hundreds of milliseconds, the kind of spike that makes a call cut out the moment a phone starts a cloud backup on the same connection.

What Good Numbers Look Like, by Activity

There's no single "good" number — what matters depends entirely on what you're doing on the connection.

• Voice calls: comfortable under roughly 200ms round trip with low jitter; most VoIP codecs have enough buffering to smooth over more than video does.
• Video calls: latency under 150ms and jitter under 30ms feels solid; a bufferbloat grade of C or worse is often the real cause of a call that cuts out whenever someone else is online.
• Online gaming: under 50ms with tight jitter is excellent for anything competitive; 50-100ms is fine for most casual and story-driven online play.
• Cloud gaming: the strictest case — under 40ms with very low jitter, because the entire video frame is round-tripped, not just an input.
• Browsing, streaming, downloads: latency barely matters here at all — see the internet speed test for the numbers that actually govern these.

That's why this test surfaces a verdict for each of these activities directly, rather than leaving you to interpret three raw numbers yourself.

Wi-Fi, VPNs, and Other Things That Inflate the Result

Before assuming a bad result means a bad internet line, rule out the things most likely to be adding latency of their own.

• Wi-Fi: adds its own latency and, especially on a congested 2.4GHz band or in an apartment building with dozens of overlapping networks, its own jitter — often more than the internet line itself contributes.
• A VPN: routes every packet through an extra server, frequently a distant one, adding real round-trip distance on top of whatever encryption overhead it costs.
• An overloaded router: an aging or underpowered router can add processing latency under load independent of your actual internet connection — this looks identical to bufferbloat from the outside.
• Background apps: cloud sync, auto-updates, and other devices on the same network can all be quietly saturating the connection during what you thought was an idle test.

The fastest way to isolate the cause: run the test wired with everything else paused, then again over Wi-Fi with your normal background load — the gap between the two tells you where the problem actually lives.

When the Result Really Does Point at a Problem

Most rough results have one of the explanations above. A smaller set of patterns is genuinely worth raising with your ISP.

• A bufferbloat grade of D or F on a wired connection, confirmed across more than one run — this is often fixable on the ISP's side with modern queue management (marketed as SQM or fq_codel) if they support it.
• Idle latency well above 100ms to a nearby Cloudflare location on a wired connection, consistently across times of day — that points at a routing or congestion issue upstream, not at anything in your home.
• A high count of unanswered probes on a wired connection with no VPN active — worth reproducing and reporting with a screenshot, since it can indicate a genuine problem on the provider's network.
• Numbers that are fine at 3am but consistently bad every evening — local network congestion, worth raising with your ISP directly with that specific pattern described.

Frequently asked questions