Measure delay to your router and to a responding internet endpoint, repeat the measurements on Ethernet and Wi-Fi, and compare idle results with results during a controlled transfer. A test of network latency becomes useful when you record the destination and conditions alongside the numbers.

To measure latency consistently, use the same device and endpoint for each comparison. Look beyond a single average: spikes and variation can disrupt a call or game even when most responses are quick. A missed response requires interpretation too; some destinations choose not to answer ping requests.

Test latency with repeatable measurements

Latency is delay. A common measurement is round-trip time (RTT): how long a probe takes to reach an endpoint and for its reply to return. It is measured in milliseconds (ms). A latency test using ping sends Internet Control Message Protocol (ICMP) echo requests and times the replies. RTT includes the return path and processing at the destination; it is not a direct measurement of one-way delay.

Download speed measures how much data arrives per second. Fast downloads can coexist with spikes during interactive tasks. Conversely, a low RTT to one nearby server does not describe every application or destination.

Before testing, identify the router’s local gateway address in your device’s network settings. On Windows, ipconfig lists the default gateway for each adapter. Choose the active adapter; a VPN or second network connection can change the route. Pick a second endpoint that responds to ping and, if possible, is relevant to your application. Record its name or IP address and keep it consistent.

Establish an idle baseline

Pause large downloads, backups and streams on the network for a few minutes, with the agreement of other users. Record the time, device, connection type and destination. Then run a series of probes:

1. On Windows, use ping -n 30 <gateway> and then ping -n 30 <endpoint>, replacing each placeholder with the actual address or name.
2. On macOS or Linux, use ping -c 30 <gateway> and ping -c 30 <endpoint>. Check the local ping manual if your system uses different options.
3. Save the minimum, average and maximum RTT, the number of replies and any visible spikes. Repeat the same series at least once.

For example, “I will test my latency to the router and the same external endpoint” gives two distinct measurements. The first covers the local path to the gateway; the second covers that path plus the route to the selected destination and back. If the router ignores ICMP, test latency to another responsive local endpoint.

A latency test is more comparable when the same address family is used throughout. A hostname may resolve to different IPv4 or IPv6 addresses or different servers over time. Use the same responding address for paired runs.

Compare wired and wireless paths

Run the sequence first over Ethernet if possible, then over Wi-Fi on the same device. Disable or disconnect the unused interface so you know which path carries the probes. Keep the endpoint, test duration and idle conditions consistent. Note your Wi-Fi location and band, then repeat at the place where the problem occurs.

If gateway delay spikes only on Wi-Fi while Ethernet remains steady, investigate signal, interference, distance and local wireless congestion. Move closer to the access point or test another channel or band supported by your devices. If both connections show similar external spikes but stable gateway responses, investigate the upstream connection or route as well. These comparisons narrow the location; they do not identify a single cause on their own.

Repeat under controlled load

To test internet latency while the connection is busy, run the same probes during a sustained download, then separately during an upload. A reputable speed-test tool that reports loaded latency can automate a similar comparison; note its server and method. Keep each run long enough to collect a comparable sample and record what else was using the network.

If delay rises sharply only during a transfer, queues may be building at a bottleneck. Try pausing competing traffic and compare again. Traffic management or smart queue management may help on supported routers. Recheck both responsiveness and throughput after a change.

Repeat the latency test at a quieter time and during the period when problems normally occur. A remote endpoint can be slower because of distance, routing, congestion or its own workload. A nearby test server is useful for comparisons, but the service you actually use may follow a different path.

Read spikes, variation and missing replies

The average describes the sample, while the maximum shows the slowest reply observed. A few high values among low ones can cause noticeable hesitation even if the average looks acceptable. Jitter describes variation in delay over time; tools calculate it in different ways, so compare results from the same tool and method. Cloudflare’s diagnostic documentation describes jitter as variation in latency.

A timeout means that a reply was not received within the tool’s waiting period. The endpoint or a firewall may block or deprioritize ICMP, so a timeout alone does not prove application traffic was lost. Microsoft notes that ICMP can be blocked by networks or firewalls. Compare another responsive endpoint and the affected application’s own behavior before drawing a conclusion.

Keep this checklist: record the endpoint and address family; measure gateway and external RTT repeatedly; compare Ethernet with Wi-Fi; repeat at idle and under upload and download load; note spikes, timeouts and time of day; then change one condition and measure again.