Troubleshoot High Latency: A Step-by-Step Decision Guide

Quick answer: to find the cause of high latency, work from the inside out: first confirm the problem is real and repeatable, then test over a cable, then test while the network is idle, then test several nearby and distant destinations at once, and finally compare with another connection. Where the problem appears or disappears tells you which layer is responsible: your device, your Wi-Fi, your router and line, your ISP, the route, or the server. This guide is written as a decision flow so you can follow it one question at a time.

Before you start: what counts as "high"?

Latency is the delay for data to reach a server and return, measured in milliseconds (ms); see what is latency. Whether a number is high depends on distance. Light in optical fibre travels at about 200,000 km/s, roughly 1 ms of round trip per 100 km of path, and real routes are longer than the straight line. Use these rough expectations for a wired connection:

Destination	Typical range	Suspiciously high
Same city or region	5 to 30 ms	Over about 60 ms
Same continent	20 to 100 ms	Over about 150 ms
Other side of an ocean	70 to 150 ms	Over about 250 ms
Opposite side of the world	150 to 300 ms	Over about 400 ms

Those are guides, not rules. Wi-Fi and mobile add more. For use-case targets see what is a good latency.

Step 1: Is the problem real and repeatable?

Run a test with several passes. With GlobeLatency, choose a handful of destinations, set the passes per destination (3 is the default; up to 20 are allowed) and run it. Look at the average, best and worst for each. Repeat once or twice over a few minutes.

• High only once, normal on repeat: a transient glitch. Note the time and move on.
• High on every run: continue to Step 2.
• Average fine but worst pass very high: the problem is instability, not general slowness. Go to the "Spikes" branch at the end, and read jitter explained.

Note that one high-looking value in a result can also be the first pass: the first request to a destination includes DNS and handshake setup, so it can be slower than later ones. See reading your results.

Step 2: Is it only one destination, or many?

Test at least five destinations in different directions, including some close to you and some far away. The live map or a multi-destination test shows them side by side.

• Only one destination is slow, others normal: the cause is at that server or on the path to it. Go to Step 7.
• Everything is slow, including nearby destinations: the cause is near you. Continue to Step 3.
• Only far destinations are slow: probably distance. Compare against the physical minimum in the table above. If the numbers match the distance, nothing is wrong; if they are much higher, the route may be poor (Step 6).

Step 3: Does a cable fix it?

Connect the computer to the router with an Ethernet cable, turn Wi-Fi off on that device, and test again.

• Much better on cable: the problem is your wireless link. Go to the Wi-Fi branch below.
• Same on cable: the cause is not Wi-Fi. Continue to Step 4.
• No cable possible (phone, laptop without port): test close to the router, in line of sight, and compare. If it improves, signal strength or interference is the issue.

Wi-Fi branch

• Move closer to the router; test again.
• Try the 5 GHz or 6 GHz network instead of 2.4 GHz.
• Change the channel if neighbouring networks overlap.
• Check for microwaves, cordless phones and other interference sources.
• Update the router firmware and the device's wireless driver.
• Consider an access point or a wired backhaul if the router is far away.

Step 4: Is something using your line?

Pause everything else: backups, cloud sync, game downloads, streaming on other devices, other people's uploads. Test again.

• Better when idle: your line was saturated and queues were building. This is often bufferbloat. Test it directly: start a large upload and watch latency on the monitor. If it jumps while the transfer runs and recovers afterwards, enable smart queue management or limit the speed of heavy transfers. See how to reduce latency.
• Same when idle: continue to Step 5.

Step 5: Is it the router, modem or device?

1. Restart the modem and router (power off for about 30 seconds, then on). Test again after they come fully back.
2. Try a second device on the same cable or network. If only one device is slow, the cause is that device: background software, a VPN, a proxy, security software, a failing network adapter or an overloaded CPU.
3. Turn off VPNs and proxies. They add a detour; see VPN and latency.
4. Try a different cable and port. A damaged cable can cause errors.
5. Check for two routers in a row (double NAT) and for unusual router features such as heavy filtering.

• Fixed: done; note what you changed.
• Not fixed on any device, on cable, idle, after restart: the cause is likely in the line or your provider. Continue to Step 6.

Step 6: Is it your ISP or the route?

If every device is slow on a cable while idle and everything nearby is high, check these signs:

• High to all destinations by roughly the same amount: an extra fixed delay on your access line or the first hops. Typical of a faulty line, a congested local node or poor signal on a mobile or satellite connection.
• Worse at the same time each evening: congestion in the provider's network, typically at peak hours.
• High only to certain regions or services: a poor route or a peering problem between your provider and that destination; see routing, BGP and peering.
• Packet loss as well: see packet loss explained. Loss with high latency strongly suggests a line fault or congestion.

To find where on the path, run traceroute (tracert on Windows) or mtr to a destination. A hop where latency jumps and stays high for all later hops marks where the delay begins. A single middle hop with high values but normal later hops is usually just a router that deprioritises replies, not a problem. Collect evidence for your provider: times, test results, a saved report link and trace output. See talking to your ISP.

Also test from a different connection (a phone's mobile hotspot, a friend's network). If the other connection is fine, your line or provider is the problem; if it is equally slow, the destination or the route from your region is the likelier cause.

Step 7: Is it the destination?

If only one destination is slow while others are fine on the same connection:

• The server may be overloaded or having an incident. Check its status page, and retest later.
• The server may be far away or on a long path; compare with its distance.
• The measurement may include server processing. A full web page URL includes the server's work; a small static file mostly measures the network. See ping vs HTTPS latency.
• If it is a service you use, try a different server or region.

"No reply" in GlobeLatency means no successful response within the timeout; it can be an actual outage, a block, or a destination that refuses these requests. See troubleshooting GlobeLatency if results look wrong.

Spikes branch: average is fine but sometimes very slow

• Run a continuous test on the monitor and note when spikes occur.
• Spikes disappear on Ethernet: Wi-Fi interference or roaming.
• Spikes coincide with transfers: bufferbloat.
• Spikes at regular intervals: a scheduled task, scanning, or a periodic router process.
• Random spikes on mobile or satellite: signal changes and handovers are normal there.
• Background tab: browsers throttle timers in background tabs, which can distort live readings. Keep the page visible while testing.

Quick decision summary

What you observe	Most likely layer	Next step
Good on cable, bad on Wi-Fi	Wireless link	Wi-Fi branch
Bad only when something uploads	Your line's queue	Smart queue management, limit transfers
Bad on one device only	That device or its software	Check VPN, security software, adapter
Good after restart	Router or modem	Watch for recurrence; replace if repeated
Bad to everything, all devices, cable, idle	Line or ISP	Collect evidence, contact provider
Bad only in the evening	ISP congestion	Log times, contact provider
Bad to one destination or region	Server or route	Retest later, try another server or route
Matches distance	Physics	Choose a closer server

Worked examples

Example 1: the evening slowdown

A user's wired latency to a nearby server is 14 ms at noon and 85 ms at 9 pm, with other devices idle and the same pattern to every destination, including a second city. Reasoning: local equipment is the same, only the time changed, so the line is shared or the provider's network is congested. The user saves test results at noon and 9 pm for three days and takes them to the provider.

Example 2: only Wi-Fi

Average to a regional server over Wi-Fi is 52 ms with worst passes of 300 ms. On Ethernet it is 19 ms with worst 28 ms. The line, the provider and the server are fine; the wireless link is at fault. Moving to a less crowded 5 GHz channel brings Wi-Fi down to 24 ms average.

Example 3: one slow server

Ten destinations all show 15 to 90 ms, matching their distances, but one, 800 km away, shows 380 ms. A phone on mobile data shows the same 380 ms. The common factor is that server, so waiting or choosing another server is the sensible response.

Common mistakes and myths

• Blaming the ISP before testing on a cable. Many problems are in the home wireless.
• Testing while other things use the line. It hides or exaggerates the result.
• Relying on one number. Use several passes and read the best and worst, not only the average.
• Trusting a high ICMP time on one hop in traceroute. Intermediate routers often delay replies without delaying traffic passing through them.
• Testing in a background tab. Browsers throttle timers there.
• Expecting low ping to far-away servers. Compare with the distance, not with an ideal.
• Restarting repeatedly without noting results. Keep a log of what you changed and when.

What to do next

Apply the fixes in how to reduce latency for whichever branch you landed in. If the evidence points at your line or provider, gather it and use talking to your ISP. Re-run the free latency test after each change and compare the saved results, and read reading your results if any number is unclear.