How to Measure Latency: ping, traceroute, and Browser DevTools Step by Step

How to Measure Latency - The Short Answer

There are three standard ways to measure latency (round-trip network delay): (1) the built-in ping command to time the round trip to a specific server, (2) traceroute to find out where along the route the delay occurs, and (3) your browser's developer tools to inspect the waiting time of real web page loads. If you prefer to skip the command line entirely, our connection quality test measures round-trip latency from your browser to servers in major cities worldwide in one run.

This article walks through each method step by step: how to run it, how to read the output, what values are considered good, and how to narrow down the cause when the numbers look bad.

Before You Measure - Latency Is Not Speed

Latency is the time it takes for data to travel to a server and back, measured in milliseconds (ms). It is also called RTT (Round Trip Time).

It is often confused with connection speed (bandwidth), which measures how much data can be transferred per second (Mbps) - a different metric entirely. If bandwidth is the number of lanes on a highway, latency is the travel time to the destination. Bandwidth matters for downloading videos; latency matters for the responsiveness of online games and video calls. If your speed test looks great but your game still stutters, latency is almost always the culprit.

Method 1: Measure Round Trips with ping

The most fundamental method. ping sends a small packet to the target using the ICMP protocol and reports how long the round trip took.

How to run it

• Windows: Search "cmd" in the Start menu to open Command Prompt, then run ping -n 10 example.com (sends 10 probes)
• macOS / Linux: Open a terminal and run ping -c 10 example.com (sends 10 probes)

How to read the output

• time=: the measured latency of each individual round trip
• avg: the representative value for your line. A single probe can be a fluke - always judge by the average of multiple probes
• packet loss: 0% is normal. Even a few percent of loss degrades perceived quality far more than the latency number suggests
• A large gap between min and max: high jitter (variation in delay), typically pointing at Wi-Fi conditions or congestion

Note that some servers are configured not to answer ICMP at all - a 100% timeout does not necessarily mean the server is down.

Method 2: Find Where the Delay Happens with traceroute

Once ping tells you the delay is high, the next question is where it happens. traceroute lists the delay at every hop (relay point) between your router and the destination server.

• Windows: tracert example.com
• macOS / Linux: traceroute example.com

The trick is to look for the hop where delay jumps. Tens of milliseconds already at hop 1 (your home router) points at your Wi-Fi environment; a jump inside your ISP's network suggests congestion; a jump just before an overseas server is simply physical distance. See how traceroute works for a full guide to reading the output.

Method 3: Inspect Real Page Loads with Browser Developer Tools

When only a specific site feels slow, the browser's developer tools are the right instrument. Unlike ping, they show the time spent on the actual HTTP requests.

Steps (Chrome / Edge / Firefox)

• Press F12 (Cmd + Option + I on macOS) to open developer tools
• Select the Network tab, then reload the page
• Click the document row at the top of the list and open the Timing breakdown

What to look at

• Connecting (TCP): time to establish the connection - network round-trip time is directly reflected here
• Waiting (TTFB): time from sending the request until the first byte comes back. Includes network delay plus server-side processing
• Content download: if this part is long, your problem is bandwidth or payload size, not latency

A long TTFB with an instant download means the bottleneck is distance or server processing, not the thickness of your pipe. Sites served through a CDN tend to show much shorter waiting times.

Method 4: Measure from Your Browser - Connection Quality Test

If you want to measure latency without touching a terminal, use our connection quality test. It sends real requests from your browser to servers in major cities around the world, measures the round-trip latency to each, and visualizes which regions your connection is "close" to.

• The values to servers in your own country are the best baseline for everyday browsing
• The values to overseas servers let you feel the relationship between physical distance and latency
• Everything runs in the browser - no app installation required

You can also check your current IP address and connection details on the IP Check-san homepage. If you want to see how a VPN changes your latency, read how VPN speed works as well.

Reference Values - What Counts as Good

Because the speed of light sets a floor on travel time, a "good" latency depends on where the server is. Typical guideline values measured from Japan are:

If your measurements are far worse than these guidelines, narrow down the cause in this order: (1) switch from Wi-Fi to a wired LAN cable and re-measure, (2) restart your router, (3) measure at a different time of day to test for evening congestion. Improvement on a cable points at your Wi-Fi setup; fast-only-at-night points at line congestion.

Frequently Asked Questions

Should I trust the ping value or the speed test value?

It depends on what you want to know. Look at latency (the ping value) for browsing and gaming responsiveness; look at bandwidth (the Mbps from a speed test) for large downloads. You need both to see the full picture of your connection.

How do I measure latency to a site that doesn't answer ping?

For servers that ignore ICMP, use the Connecting (TCP) time in your browser's developer tools as a stand-in. It measures the real HTTP connection, so it works even when ICMP is blocked.

Can I measure latency on a smartphone?

Yes. Open our connection quality test in your phone's browser - no app needed. Comparing the values with a computer on the same Wi-Fi tells you whether the problem is the device or the line.

Summary - Match the Method to the Question

An efficient workflow is: ping to grasp the current state, traceroute to locate the slow segment, then developer tools to inspect an individual site. Once the numbers mean something to you, a vague complaint of "the internet is slow" turns into a concrete, fixable diagnosis.