Ping, Jitter & Loaded Latency Explained

What is ping (latency)?

Ping — usually just called latency — is the round-trip time for a small message to travel from your device to a server and back, measured in milliseconds. It has nothing to do with how much data your connection can move; it's purely about delay.

Think of it like asking a question out loud. If you ask someone standing next to you in the same room, you get an answer almost instantly. If you have to shout the same question across a canyon, or place a long-distance phone call to someone on another continent, the reply takes noticeably longer to come back — even though you said the exact same sentence. Latency works the same way: the physical distance to the server, the number of network hops in between, and the quality of your local connection (Wi-Fi vs. wired, congested vs. clear) all add up to the delay you see. Lower is better, and anything under about 20 ms is generally imperceptible to a person.

What is jitter?

Jitter is how much that round-trip time varies from one message to the next, rather than the delay of any single message. A connection can have a great average ping and still feel unstable if that number swings wildly between requests.

Picture a metronome that's supposed to click every second. If it clicks reliably — tick, tick, tick, at an even, predictable pace — a musician can play along without thinking about it, even if the tempo is a little slow. Now imagine that same metronome speeding up and slowing down unpredictably: sometimes 0.8 seconds between clicks, sometimes 1.4 seconds. That's far harder to play along with than a metronome that's consistently a bit slow. Jitter is that unpredictability applied to your network: a steady 60 ms ping is easier for a video call or a game to work around than a ping that jumps between 20 ms and 150 ms from one moment to the next, because the receiving app can't predict when the next piece of data will actually arrive. That's why a single fast ping reading tells you much less than a consistent one — real-time apps care about predictability at least as much as raw speed.

What is loaded latency (and bufferbloat)?

Loaded latency is your round-trip time measured while the connection is simultaneously busy — actively downloading or uploading a large amount of data — instead of sitting idle. It answers a different question than idle ping: not "how fast is my connection when nothing else is happening," but "how fast does it stay when something else is happening at the same time."

The usual cause of a big gap between idle and loaded latency is called bufferbloat. Imagine a single-lane road with a large buffer area in front of a tollbooth, designed so cars never have to stop and wait — they just queue in the buffer instead. That works fine for light traffic. But if a slow-moving truck gets in that lane and the buffer fills up with cars behind it, every car back there is now stuck waiting in a long line, even ones that would otherwise have sailed through instantly. Home routers and modems do the same thing with data: they hold outgoing and incoming packets in a memory buffer so nothing gets dropped. When a big download or upload fills that buffer, every other packet — including the tiny, time-sensitive ones for your video call or game — has to wait in line behind it.

This is why a connection can post an excellent idle ping and still feel awful the moment someone else in the house starts a large download, a cloud backup kicks in, or you upload a big file: the pipe isn't out of bandwidth, it's out of queue space, and everything sharing that connection is stuck waiting behind the same backed-up traffic.

Reading your own result

When you run a test on this site, you get four latency-related numbers, and they're meant to be read together, not one at a time:

• Idle latency — your baseline round-trip time with nothing else competing for the connection. This is the number closest to a "best case."
• Jitter — how much that idle latency bounced around between samples. A low number means your baseline is consistent; a high number means even idle conditions aren't stable.
• Download-loaded latency — round-trip time measured while the download portion of the test is actively pulling data. A large jump above idle latency here points to bufferbloat on incoming traffic.
• Upload-loaded latency — the same idea, measured while uploading. Many home connections — especially cable and older DSL — show more bufferbloat on upload than download, because upload bandwidth is usually the smaller, more easily saturated side of the connection.

A connection with a low idle ping, low jitter, and loaded latency numbers close to that idle baseline is genuinely well-behaved under real-world conditions. A connection with a low idle ping but loaded latency that jumps by 100 ms or more only looks good when nothing else is happening on it — which in a real household, with other devices, updates, and backups running in the background, is rarely the case. For the exact millisecond ranges we use to label each of these as excellent, good, or poor, see our methodology page.

Which activities actually care

How much any of this matters depends entirely on what you're doing:

• Competitive online gaming cares about all three: a low idle ping so your inputs register quickly, low jitter so that timing stays predictable round after round, and low loaded latency so a game doesn't spike or lag the moment a download starts elsewhere on the network. See our gaming guide for specifics.
• Video calls are more forgiving of a moderately higher idle ping, but very sensitive to jitter and loaded latency — that's what causes choppy audio, frozen video frames, and people talking over each other because a reply arrived late. Details in our video calls guide.
• Casual web browsing, email, and most streaming barely notice any of these numbers. Pages and video buffer ahead of time, so an extra 50–100 ms of delay, or some jitter under load, is rarely something you'd feel.

If your numbers look concerning, the most useful next step is usually to run the test again while nothing else is using the connection, then again while something is — that comparison alone will tell you whether bufferbloat is the issue.