Latency is the time a packet takes to get from you to a destination and back. It's measured in milliseconds, and it's the number that determines whether SSH feels instant, whether your video call stutters, and how fast a page starts loading. Bandwidth determines how fast the page finishes loading. Those are different problems, and the first mistake most people make is testing one when they care about the other.
This guide covers measuring latency properly: which tools to use, how to read the output, and how to capture numbers you can actually compare later. If your goal is to fix high latency, read how to reduce network latency after this one.
Latency is not bandwidth
A 1 Gbps connection with 200 ms latency feels worse for interactive work than a 50 Mbps connection with 15 ms latency. Bandwidth is the width of the pipe; latency is the length of it. A speed test measures the first. None of the tools in this guide measure throughput; they measure round-trip time (RTT), and that's deliberate.
Three numbers matter:
- RTT: round-trip time per packet, in ms.
- Jitter: variation in RTT between packets. Low average RTT with high jitter still wrecks VoIP and gaming.
- Packet loss: percentage of packets that never came back. Anything consistently above 0% on a wired connection is worth investigating.
Step 1. Pick targets worth testing
Test the thing you actually care about, plus a stable reference point:
- Your application's server: the hostname your slow app talks to.
- A public anycast resolver:
1.1.1.1or8.8.8.8. These are close to almost everyone and give you a "best case" baseline. - Your default gateway: your router's IP. This isolates the local hop.
If you don't know your public-facing position on the network, check What's My IP first; it confirms which network and ISP you're testing from, which matters when you compare results later.
Step 2. Run ping and read it properly
ping -c 20 1.1.1.1
On Windows, ping -n 20 1.1.1.1. Twenty packets is the minimum for a meaningful sample; a 4-packet default proves nothing.
The summary line is what you keep:
20 packets transmitted, 20 received, 0% packet loss
rtt min/avg/max/mdev = 8.412/9.103/14.882/1.337 ms
- min: the best the path can do. Closest to the "true" latency of the route.
- avg: your headline number.
- max: one bad outlier is fine; a max far above min on every run suggests queueing.
- mdev (standard deviation): your jitter proxy. Under a few ms is good; tens of ms means an unstable path.
Rough expectations on a wired connection: single digits to your ISP's nearest infrastructure, 10-40 ms within your region, 70-100 ms cross-continent, 150 ms+ intercontinental. The speed of light in fiber sets a hard floor: you cannot ping Sydney from London in 20 ms, and no upgrade changes that.
If you can't run a terminal where you are, the Ping Test tool runs the measurement from our infrastructure to your target, useful for checking a server's reachability and RTT from outside your own network.
Step 3. Test the path, not just the endpoint
A single RTT number tells you the path is slow, not where. Traceroute shows per-hop timing:
traceroute example.com # macOS/Linux tracert example.com # Windows
Better: mtr, which is traceroute and ping combined, sending continuously and accumulating statistics per hop:
mtr --report --report-cycles 50 example.com
Reading the output:
- Look for the hop where average RTT jumps and stays high for every hop after it. That's where the delay enters the path.
- A single hop with high RTT but normal hops after it is usually a router de-prioritising ICMP replies to itself, not a real problem.
- Loss that appears at one hop and persists to the destination is real loss. Loss at one hop only is, again, usually ICMP rate-limiting.
If the slow hop is hop 1, your problem is local (Wi-Fi, router). Hops 2-4, it's your ISP. Later hops, it's transit or the destination's network. Run IP Geolocation on hop IPs to see roughly where the path goes; a route that detours through another country explains a lot of "mystery" latency.
Step 4. Measure under load (bufferbloat)
Idle latency and loaded latency are different measurements, and the second one is what users feel. Bufferbloat (oversized queues in your router or modem filling up during transfers) can take a connection from 12 ms idle to 400 ms while anything is uploading.
Test it yourself: start a continuous ping in one terminal, then saturate the link (a large upload is the usual trigger):
# Terminal 1 ping 1.1.1.1 # Terminal 2 - push sustained upload traffic, e.g. copy a large file to cloud storage
If RTT climbs by hundreds of milliseconds during the transfer and recovers when it stops, you have bufferbloat. The fix (SQM/smart queue management) is covered in how to reduce network latency.
Step 5. Don't forget DNS and HTTP-level latency
ICMP RTT isn't the whole story for web traffic. Before any HTTP request, the client resolves a name, and a slow resolver adds its delay to every new connection. Time it directly:
dig example.com | grep "Query time"
Anything over ~50 ms for an uncached lookup against your configured resolver is worth comparing against 1.1.1.1 or 8.8.8.8. The DNS Lookup tool shows you what's being resolved and from where; how to perform a DNS lookup covers the workflow.
For full request timing including TLS handshake and time-to-first-byte:
curl -o /dev/null -s -w "dns: %{time_namelookup}s connect: %{time_connect}s tls: %{time_appconnect}s ttfb: %{time_starttransfer}s\n" https://example.com
One caveat when testing big sites: most are behind a CDN, so you're measuring RTT to the nearest edge node, not their origin. Great latency to google.com proves your last mile is fine; it says nothing about the path to your own un-CDN'd server.
Step 6. Record a baseline and test at different times
A single measurement is a data point; a baseline is what makes the next measurement meaningful. Capture, for each target: min/avg/max/mdev, loss %, time of day, and wired vs Wi-Fi. Repeat at peak hours (evenings for residential connections); congestion-related latency is invisible at 10 a.m. and obvious at 9 p.m.
For servers you operate, don't do this by hand: a website uptime monitor checks on an interval and records response time over time, so you have the trend already graphed when someone says "the site feels slow."
TL;DR
- Latency ≠ bandwidth. Measure RTT, jitter, and loss, not Mbps.
ping -c 20against your target,1.1.1.1, and your gateway. Keep min/avg/max/mdev.mtr --reportto find where on the path the delay enters.- Ping under load to detect bufferbloat; loaded latency is what users feel.
- Check DNS resolution time and
curltiming for web targets; remember CDNs mask the origin path. - Baseline at multiple times of day, or let a monitor do it continuously.
Related
- How to reduce network latency: fixing what you just measured
- How to diagnose a slow internet connection: the broader troubleshooting workflow
- Ping Test tool: RTT measurement from our infrastructure