title: How to reduce network latency description: Practical fixes for high latency: bufferbloat and SQM, wired over Wi-Fi, faster DNS, CDN and edge placement, and connection reuse. Ordered by impact. heroImageAlt: "Green paper plane rising along a dashed path between two dots, beside a small chart showing a falling curve, on a dark grid" date: 2026-06-10 tags: [networking, latency, optimization] author: Trace Warrior Team
You can't optimize what you haven't measured, so if you haven't already, start with how to test network latency and come back with numbers: idle RTT, loaded RTT, jitter, and an mtr report showing where on the path the delay lives. This guide assumes you have those and walks through the fixes, roughly ordered by how often they're the actual problem.
One framing rule before anything else: latency has a physics floor. Round-trip time can never beat the speed of light through fiber over the route distance, plus per-hop processing. If your idle RTT to a server 100 km away is 8 ms, there is nothing to "reduce"; that's the path. Optimization is about removing excess latency: queueing delay, bad routing, slow lookups, and unnecessary round trips. Most real-world wins come from those four.
Fix bufferbloat first: it's usually the biggest win
If your idle latency is fine but everything turns to mud when someone uploads a video or a backup runs, the problem is bufferbloat: oversized buffers in your router or modem queueing hundreds of milliseconds of packets during saturation. You confirmed this in the testing guide by pinging during a sustained upload and watching RTT climb from ~15 ms to 300+ ms.
The fix is smart queue management (SQM): modern AQM algorithms (fq_codel, CAKE) that keep queues short.
- Check your router's settings for "SQM", "Smart Queue", "QoS (fq_codel/CAKE)", or vendor names like "Dynamic QoS". OpenWrt, most prosumer routers (Ubiquiti, MikroTik, Firewalla), and some ISP firmware support it.
- Set the shaper bandwidth to roughly 90-95% of your real measured up/down throughput. SQM works by making your router the bottleneck so it controls the queue, not the modem's dumb buffer.
- Re-run the loaded-latency test. A good result is RTT rising only a few ms under full load.
This single change does more for perceived responsiveness on a busy connection than any bandwidth upgrade. Note that SQM is the modern replacement for hand-tuned QoS priority rules; port-based QoS classes still have a place on managed business networks for protecting VoIP, but for "my connection lags under load," queue management is the actual fix.
Get off Wi-Fi for anything latency-sensitive
Ethernet adds well under a millisecond. Wi-Fi adds a variable amount: often a few ms in good conditions, but retransmissions from interference, distance, or congestion turn that into spikes of tens to hundreds of ms. That's jitter, and jitter is what kills calls and games even when average RTT looks fine.
- Cable anything stationary that matters: desktop, console, VoIP base station.
- If you must use Wi-Fi: prefer 5 GHz/6 GHz over 2.4 GHz, reduce distance and obstructions, and pick a channel that isn't shared with every neighbor.
- Powerline and mesh backhauls are middle ground: better than weak Wi-Fi, worse than copper.
Compare ping -c 50 to your gateway over Wi-Fi vs Ethernet. The mdev (jitter) difference is usually more dramatic than the average.
Cut DNS resolution time
Every new connection starts with a name lookup, and a slow or distant resolver taxes everything. This doesn't change RTT to a server, but it changes how fast connections start, which is what users perceive as speed.
dig example.com @1.1.1.1 | grep "Query time" dig example.com # your current resolver, for comparison
If your ISP's resolver is consistently slower than 1.1.1.1 (Cloudflare) or 8.8.8.8 (Google), switch, at the router level so every device benefits. Verify what's actually resolving and how with the DNS Lookup tool.
If you operate the domain being looked up, also check your own records' TTLs: very short TTLs force clients to re-resolve constantly. The lookup workflow is covered in how to perform a DNS lookup.
Shorten the path: CDN and edge placement
For traffic you serve, the most effective latency reduction is moving content closer to users. You cannot make the speed of light faster, but you can make the distance shorter.
- Static assets behind a CDN. A user in Singapore hitting your Frankfurt origin pays ~170 ms per round trip; hitting a Singapore edge node pays single digits. Since a TLS connection costs multiple round trips before the first byte, the multiplier is large.
- Check what's actually being served from where. Run the HTTP Header Checker against your URLs; CDN responses carry telltale headers (
cf-ray,x-cache,x-served-by,age).x-cache: MISSon supposedly cached assets means your CDN is configured but not helping. - Dynamic traffic: pick hosting regions near your users, and consider edge compute for the latency-critical path. Use IP Geolocation on your server's IP and on a sample of client IPs to sanity-check the geography.
Reduce round trips at the protocol layer
When the path length is fixed, the remaining lever is how many times you traverse it:
- Keep connections alive. TCP + TLS setup costs 2-3 round trips before any data. HTTP keep-alive and connection pooling pay that once instead of per request.
- TLS 1.3 cuts the TLS handshake to one round trip (and supports 0-RTT resumption). If your server still negotiates TLS 1.2, that's a free round trip on every fresh connection.
- HTTP/2 or HTTP/3 multiplex requests over one connection; HTTP/3 (QUIC) additionally avoids TCP head-of-line blocking on lossy paths.
- Compression and payload size don't change RTT, but fewer packets means fewer chances to hit loss-triggered retransmits, which are pure added latency.
These are server-side changes, and they compound: TLS 1.3 + keep-alive + a nearby edge node routinely turns a 600 ms first byte into under 100 ms with zero infrastructure moves.
When the path itself is the problem
Your mtr report sometimes shows the delay entering at a transit hop you don't control: a route that detours geographically, or persistent loss mid-path. Options, honestly limited:
- Residential: report it to your ISP with the mtr report attached. Evidence of where loss/delay starts is the difference between a ticket that goes somewhere and one that doesn't.
- Business/server traffic: some hosts and ISPs offer better-peered routes; multi-homed providers and CDNs with private backbones effectively buy you better paths. Moving providers is sometimes the only fix for chronically bad routing.
Don't fall for "route optimizer" gimmicks for general traffic; if the slow hop is inside a carrier's network, no local setting changes it.
Verify, then keep watching
After each change, re-run the same tests from the testing guide so you're comparing like with like: idle RTT, loaded RTT, jitter, and curl timing for web endpoints. Latency regressions also creep in silently: a CDN config change, a route flap, a resolver slowdown. For services you're responsible for, put a website uptime monitor on the endpoint so response-time trends are recorded continuously instead of discovered by complaint.
TL;DR
- Measure first: test network latency and find where the delay is before touching anything.
- Enable SQM (fq_codel/CAKE) on your router; bufferbloat is the most common fixable cause of lag under load.
- Use Ethernet for anything latency-sensitive; Wi-Fi's real cost is jitter.
- Switch to a fast DNS resolver and verify with DNS Lookup.
- Serve content from a CDN/edge near users; confirm cache behavior with the HTTP Header Checker.
- Cut round trips: keep-alive, TLS 1.3, HTTP/2/3.
- Re-measure after every change, and monitor continuously.
Related
- How to test network latency: the measurement half of this workflow
- How to diagnose a slow internet connection: when the symptom is "everything is slow" and you don't yet know why
- Ping Test tool: quick RTT checks against any host