Latency and ping: why fast internet still isn't enough

The short version

Speed is how much data you can move. Latency (also called ping) is how long it takes for a message to make the round trip to the internet and back. A big fast pipe can still feel slow if every click waits — and lowering latency often does more for calls and games than buying more speed.

What's actually happening

Imagine shouting a question across a canyon and waiting for the echo. Latency is that wait, measured in milliseconds (ms) — thousandths of a second. It's the delay before the data arrives, no matter how much data is coming.

Every click, every "your turn" in a game, every spoken word on a call makes that round trip. If the trip takes 20 ms, things feel instant. If it takes 200 ms, everything feels sticky — even on a "fast" plan.

Why it matters to you

• Online games feel laggy and unfair — you act, but the game reacts late.
• Video calls have that awkward "no, you go" talking-over-each-other delay.
• Web pages feel slow to start loading, even when they download fast once they begin.
• Latency, not speed, is usually what makes the internet feel "slow."

How to measure it

You can check your latency in a minute. Lower numbers are better.

On Windows 11

1. Click Start, type cmd, and open Command Prompt.
2. Type ping google.com and press Enter.
3. Read the time= numbers. Those are your latency in milliseconds.

On a Mac

1. Open Terminal (in Applications, then Utilities — or search for it with Spotlight).
2. Type ping google.com and press Enter.
3. Watch the time= numbers, then press Control + C to stop.

What's good? Under about 30 ms on wired, or under 50 ms on Wi-Fi, is great. Over 100 ms when nothing else is running usually means something's wrong.

How to fix it

Step 1: The free fixes

1. Use a cable. Plugging your computer or console into the router with a network (Ethernet) cable almost always lowers latency versus Wi-Fi.
2. Get closer to the router if you must use Wi-Fi, and use the 5 GHz network.
3. Restart the modem and router (unplug 30 seconds; modem first, then router).
4. Pause big uploads and downloads while you test — a busy connection raises latency for everyone. (That spike under load has its own name, bufferbloat, and its own fix.)

Step 2: Check your equipment

• If you have cable internet, an old or failing modem can add delay. Make sure your modem is a current DOCSIS 3.1 model that your provider approves. See the gear below.
• If you game, a router with good QoS (which keeps game traffic moving when the line is busy) helps — but a wired connection matters more.

Step 3: Turn on smart queueing in your router

Most of the "lag when the house is busy" problem is fixed by a router feature called QoS or Smart Queue Management:

• ASUS: router.asus.com → Adaptive QoS (newer models: Adaptive QoE) → turn QoS on.
• Netgear: routerlogin.net → Dynamic QoS → Enable, then enter or detect your speed.
• TP-Link: Tether app → HomeShield/HomeCare → QoS.
• eero / Google Nest Wifi: handled automatically; little to change.

What you can't fix

Some latency is just distance. A game server across the country, or satellite internet, has a floor set by physics — no gear removes it. The honest goal is to remove the extra delay your own setup adds, not the unavoidable part.

How to check it worked

Run ping again the same way. You want a low, steady number with no big jumps. Compare wired to Wi-Fi: if wired is much lower, use the cable for the things that matter. If your numbers stay high even wired with nothing else running, the delay is likely outside your home — that's a provider conversation.

If your result was already good

If your latency is low and steady, you're in great shape — you don't need to change or buy anything. Keep your router firmware updated, and use a wired connection for gaming or important calls to keep it that way. Re-check if you switch providers or add satellite/fixed-wireless internet, which behave differently.

Want to go further?

The Advanced version covers reading tracert/pathping to find where the delay is, idle vs loaded latency, DNS vs network delay, and how to build a case before you call your ISP.

Is this your problem?

Latency (ping) is what these searches are really about:

• "Why is my ping so high but my internet is good?" and "why is my ping spiking?" Bandwidth and latency are separate; a fast line can still have high or unstable ping.
• "Ping spikes every few seconds," or only when the house is busy. That points to loaded latency (bufferbloat), covered in its own guide.
• Competitive play in Valorant, CS2, League of Legends or Fortnite. Latency, not raw speed, decides whether the game feels responsive.

Summary

Latency is round-trip time (RTT), and it's the dominant factor in perceived responsiveness for interactive workloads. Diagnosis is about decomposition: separate idle RTT from loaded RTT, separate first-hop (LAN/Wi-Fi) delay from access-link delay from path/peering delay, and separate name-resolution delay from transport delay. Only then do you know which fix applies.

What latency actually is

RTT is the sum of propagation delay (distance / speed of light in the medium), serialization delay (packet size / link rate), queueing delay (time spent in buffers), and processing delay (routing, NAT, encryption). For home users the controllable terms are queueing and first-hop; propagation to a distant server is a hard floor. A gigabit link doesn't reduce propagation or queueing — bandwidth only shrinks serialization delay, which is already negligible for small interactive packets.

Measure it properly

Baseline (idle) RTT

• Windows: ping -n 50 1.1.1.1 for a stable sample; use an IP to exclude DNS. Read min/avg/max and the mean-deviation.
• macOS/Linux: ping -c 50 1.1.1.1, then read the rtt min/avg/max/mdev summary line.
• Ping both your default gateway (first hop) and a public anycast resolver. Gateway RTT should be ~1-3 ms wired; if the gateway itself is slow, the problem is LAN/Wi-Fi/CPE, not the WAN.

Per-hop decomposition

• Windows: tracert -d 1.1.1.1 lists hops with three timing probes each; -d skips reverse DNS. For loss + latency per hop over a longer window, pathping -n 1.1.1.1 (sends 100 queries/hop by default; takes minutes).
• macOS/Linux: traceroute -I 1.1.1.1 (ICMP mode; macOS defaults to UDP probes). For a combined continuous view install mtr (mtr -rwzbc 100 1.1.1.1) — the best single tool for localizing per-hop latency and loss.
• Read it correctly: a single mid-path hop showing high RTT while later hops are low means that router simply deprioritizes ICMP to its own control plane — it is not a fault. Latency that rises at a hop and stays elevated through every subsequent hop is the real signal.

Idle vs loaded

Run a sustained ping while saturating the link in both directions. A large RTT increase under load is bufferbloat — queueing delay in an unmanaged buffer, fixed by SQM (fq_codel/CAKE), not by more bandwidth. This is the single most common cause of "high ping while someone's uploading."

Localize the cause

• First hop / Wi-Fi: high and variable gateway RTT over Wi-Fi but low over Ethernet means airtime contention, low RSSI/MCS, or a congested channel. Wire the device, or fix the RF (band, width, channel, distance).
• CPE / access link: on DOCSIS, check the modem status page for upstream power (ideally under ~50 dBmV), downstream SNR/MER (35 dB+ for 256-QAM), and FEC uncorrectable error counts. Marginal RF causes retransmits and jittery RTT. Confirm the modem is DOCSIS 3.1 and on the ISP's approved list.
• Peering / distance: if idle RTT is fine to the first few hops but balloons at an inter-provider boundary, that's a routing/peering reality you can't fix locally. Document it; a VPN occasionally routes around a bad path but usually adds RTT.
• DNS vs transport: if pages feel slow to start but ping is low, you have a name-resolution delay, not a network latency problem. Test with nslookup/dig timing and try a fast resolver (1.1.1.1, 8.8.8.8, 9.9.9.9).

Fixes, in order of impact

1. Wire the latency-sensitive device. Removes Wi-Fi queueing and retransmit jitter entirely.
2. Enable SQM (CAKE or fq_codel) on the router, shaped to ~90% of line rate, to kill loaded-latency spikes. On ASUS use Adaptive QoS/QoE or flash ASUSWRT-Merlin for cake; OpenWrt/pfSense/OPNsense for full control.
3. Fix RF for Wi-Fi clients: 5/6 GHz, appropriate channel width, clean channel, adequate RSSI.
4. Replace an under-spec or failing modem (DOCSIS 3.1, correct channel bonding).
5. Choose nearer game/app servers where you can; propagation is a floor you can only shorten by shortening distance.

Verify

Re-run idle and loaded ping and confirm: low min, low avg, small max-min spread, and minimal increase under load. For gaming, the metric that matters is loaded RTT and its variance, not the idle best case. Keep a before/after capture (ping summary or an mtr report) so you can quantify the change and, if needed, hand your ISP hard evidence rather than "it feels laggy."

Edge cases & gotchas

• Satellite / GEO has ~500-600 ms RTT floor from orbital distance; LEO (Starlink) is far lower but still variable. No local fix changes the floor.
• Power-saving on laptops/phones parks the Wi-Fi radio and spikes first-ping latency; the second ping is the honest one.
• ICMP deprioritization makes raw ping to a router overstate real latency; trust end-to-end RTT and loaded behavior over a single mid-path hop.
• Double NAT / CGNAT adds minimal latency but can complicate measurement and some game matchmaking.

Why bandwidth doesn't help (the math)

For a 64-byte interactive packet, serialization delay at 100 Mbit/s is about 5 microseconds; at 1 Gbit/s it's 0.5 microseconds. Upgrading from 100 Mbps to 1 Gbps therefore shaves roughly 4.5 microseconds off that packet's delay — invisible next to a 20-40 ms propagation RTT. This is the quantitative reason "just buy more speed" almost never fixes latency: you're optimizing a term that's already negligible. The terms that matter — propagation and queueing — are untouched by bandwidth. Queueing you control with SQM; propagation you control only by moving the endpoint closer.

Lag spikes vs sustained latency

Separate the two failure modes. Sustained high idle RTT is a path/distance/CPE issue — consistent across samples. Spikes are intermittent: periodic large values among otherwise-low samples, usually from Wi-Fi power-save wakeups, channel scans, retransmit bursts, a neighbor's interference, or a background flow briefly filling the buffer. Capture a long run (ping -n 300) and look at the distribution, not the average: a 25 ms average hiding 5% of samples at 300 ms will ruin a game while looking "fine" on a summary line. For competitive play, the P95/P99 loaded RTT is the number that predicts experience.