Two video calls go badly. The first one is clearly lagged from the start — your colleague's mouth moves half a second before the audio catches up, but at least it's predictable, and the pattern doesn't change. The second one is mostly fine, then suddenly freezes for two seconds, recovers, freezes again. Those two calls have the same headline complaint ("the call was bad") but different ping signatures and different fixes.
If you only look at the average ping number, you'll miss the difference. The first call had high latency, low jitter, no loss. The second had low average latency but huge jitter and occasional packet loss. Here's how to read each signal and tell which one is the real problem.
What ping actually measures
Ping measures round-trip time. You send a probe to a server; the server replies; you measure how long the round-trip took. The result is in milliseconds. That's it. Ping doesn't tell you bandwidth — a 10 Mbps link and a 1 Gbps link can have identical ping numbers if they're physically the same distance from the server. Ping also doesn't tell you whether the slowness is in one direction or both; a high RTT could mean a slow outbound path, a slow return path, or both. Tools like mtr and traceroute expose the per-hop picture, but they require ICMP and elevated privileges, so they live on the command line, not in a browser.
Latency, jitter, and packet loss — three different problems
Latency is the average round-trip time. It drives how an interactive connection feels — typing in a remote SSH session, the click-to-response delay in a game, the gap between you speaking and your audio reaching the other side of a call. Latency is steady; the average doesn't lie about the underlying physics of the path.
Jitter is the variation around that average. A connection with 50 ms latency and 5 ms of jitter feels steady. A connection with 50 ms average latency but spikes to 500 ms once a second feels broken — even though the average is the same. Jitter is what destroys real-time audio and video, because the receiver has to buffer to absorb the variation, and when the variation overruns the buffer, the call freezes.
Packet loss is the percentage of probes that never come back at all. Below 1% is fine for most things. 1-3% will cause sluggish web browsing as TCP retransmits kick in. Above 5% is broken. Voice and video calls degrade earlier than that, because UDP doesn't retransmit — a lost packet is just gone, and the codec has to paper over the gap.
Why browser-based ping is HTTP, not ICMP
The ping command-line tool sends ICMP echo packets. Browsers can't. ICMP requires raw socket access, which every modern operating system gates behind elevated privileges. The browser sandbox doesn't have those privileges, and it shouldn't — you don't want every web page firing raw network probes from your machine.
So browser-based ping tools cheat: they measure the time to load a tiny image over HTTPS. That captures the round-trip but adds TLS handshake overhead, HTTP/2 stream setup, and image decode time on top of the pure network cost. The numbers run 20-40 ms higher than a CLI ping to the same host. The relative comparisons (one host slower than another, jitter patterns, loss) are still meaningful — but the absolute numbers aren't directly comparable.
Typical numbers — what to expect
Rough guide for a healthy connection in 2026:
- Wired home broadband to nearby CDN: 5-30 ms.
- Wi-Fi adds: 5-15 ms and some variability.
- Mobile 5G: 15-40 ms.
- Mobile 4G: 30-80 ms.
- Across an ocean: add roughly 100 ms each way for the great-circle distance.
- Satellite (Starlink LEO): 30-60 ms — surprisingly close to fibre.
- Satellite (geostationary): 600 ms+ and there's nothing you can do about it. The speed of light has to cover 36,000 km each way.
For perspective: 200 ms is the threshold where interactive work starts to feel sluggish. 500 ms is where typing in a remote terminal becomes frustrating. Above 1 second, something is broken — either the path or the server.
Diagnosing intermittent slowness
A consistent 200 ms is annoying but predictable. Spikes from a 50 ms average to 1000 ms — that's jitter, and it's what breaks video calls. Packet loss patterns are diagnostic too: scattered single losses suggest Wi-Fi interference or a flaky cable. Bursty losses (a clump of 5-10 in a row) suggest congestion or an overloaded hop, often during peak evening hours when an ISP's contention ratio bites.
The single most useful technique: compare ping results to multiple destinations. If Google, Cloudflare, and GitHub all show the same pattern of jitter and loss, the bottleneck is local — your Wi-Fi, your router, your ISP's first hop. If only one target shows the problem and the others are clean, the issue is somewhere on the path to that specific destination, and there's nothing you can do from your end except wait it out or route around it via a VPN.
Wi-Fi deserves its own paragraph because it's the single most common source of jitter in home networks. A wired connection to your router will usually show low, stable jitter. Move to Wi-Fi and the same test will show occasional 100-300 ms spikes — that's the radio retrying a frame, contending for airtime with neighbouring networks, or losing a packet to interference from a microwave or a Bluetooth device. If the wired test is clean and the Wi-Fi test is spiky, the problem is between your laptop and the router, not between your router and the rest of the internet.
Time-of-day matters too. Many home connections share capacity with neighbours — DOCSIS cable, FTTN DSL, and most fixed-wireless setups all suffer at peak hours. A network that pings clean at 10am and spikes at 9pm is congestion, not your hardware. Pure fibre (FTTP) is usually immune to this; older technologies are not.
When to use the ping check tool here
The ping check tool on this site samples 10 probes against Google, Cloudflare, and GitHub — three independent networks — and computes min, average, max, and median for each. It's designed for the question: is my connection the problem, or is that specific site having a bad day? Open it before joining a video call, or when a particular service starts feeling slow and you want to rule out the local link before opening a ticket.
Related reading
If you've confirmed latency is fine but you're still wondering about throughput, the why every speed test gives you a different number guide covers the related question of bandwidth measurement. The connection quality tool measures real single-stream throughput, and the what is my IP page is the quickest check that your network is even online.