Ping, jitter and latency explained

What the terms actually measure

• Latency: delay between specified events. It can describe one-way travel or a round trip; this tool reports browser request timings in milliseconds.
• Ping: often used informally for round-trip delay. The traditional ping utility uses ICMP; a browser HTTP request includes different processing and can produce a different result.
• Jitter: variation in delay. Several definitions exist, so two services can publish different values for the same connection.
• Packet loss: packets failing to arrive. This tool does not measure a packet-loss percentage. Stutter alone cannot establish that loss is occurring.

How this page calculates its numbers

The test makes a warm-up request, then takes 20 small HTTP request timings. Idle latency is their median. Where Cloudflare supplies server-processing timing, the implementation subtracts it. Other browser, transport and network effects remain; the result is not a clean measurement of propagation delay.

Jitter here is the mean absolute difference between consecutive readings. For an illustrative sequence of 20, 22, 21 and 29 ms, the changes are 2, 1 and 8 ms. Their mean is 11 ÷ 3 ≈ 3.67 ms. This four-reading example explains the formula; the tool uses its full sample.

Compare idle and loaded delay separately

During download and upload, the test continues timing small requests and reports a median for each busy phase. A rise under load can be consistent with queues filling, but Wi-Fi contention, device processing, browser scheduling and the route or server can also contribute.

For example, an idle result of 18 ms, download-loaded result of 60 ms and upload-loaded result of 140 ms give increases of 42 and 122 ms. The tool uses the larger increase, 122 ms, for its C grade. That local heuristic identifies a comparison worth investigating; it does not locate a fault or certify how a call will behave.

Judge results against the application and destination

A low, steady request time is generally desirable for interactive use, but there is no single pass mark for every game, meeting service or location. A nearby test endpoint and a distant game server follow different paths. A game’s in-app network display is a better comparison for that game than expecting it to equal this result.

Compare like with like: the same endpoint, device, method and workload. A small median can hide occasional delays, and a brief sample may miss an intermittent problem. Do not interpret a low jitter result as a packet-loss test.

Investigate one condition at a time

1. Reproduce the affected activity and note its destination, time and any application network statistics.
2. Compare a wired trial with Wi-Fi near the router and in the affected room.
3. Compare quiet use with the backup, upload or download that coincides with the symptom.
4. Pause or rate-limit one nonessential transfer and repeat. If responsiveness improves, investigate traffic scheduling or supported queue management.
5. If the symptom persists across capable devices and wired tests, provide the recorded comparisons to your provider or application support.

Keep required security software and workplace VPN policies in place. A permitted comparison with another route can provide evidence, but a VPN can improve or worsen delay and is not a universal fix. For queue-management options, read the bufferbloat guide.