You’ve probably had a day where a page sits there loading for five or six seconds and someone says the Wi-Fi is acting up again. Sometimes that’s true, but usually two or three smaller things are going on at once.
A lot of people end up paying for a faster internet plan when the real problem is how long each request takes to go back and forth. Others swap out a router that was working fine, while a proxy somewhere in the chain is adding around 400 ms to every request.
So it helps to measure a few things separately, and in a sensible order, before you change anything.
Check latency before you look at bandwidth
Bandwidth is basically how much data can move at once, and latency is how long it takes one packet to get somewhere and come back. For normal web browsing latency usually matters more, because a new HTTPS request needs several round trips (DNS lookup, TCP handshake, TLS setup and then the request itself) before anything shows up on screen.
That’s why a 300 Mbps fiber line with 180 ms of latency can honestly feel slower than a 50 Mbps line sitting at 20 ms. Run ping against a server close to you and one far away, and anything under 30 ms to a regional host is pretty healthy while 100 ms or more is worth looking into.
If your traffic goes through a proxy, it’s a good idea to test that path by itself too. A quick run through a proxy tester online will tell you whether the proxy responds, how fast it answers and which location it reports, which takes about a minute and can save you from spending a whole afternoon on the wrong part of the setup.
Packet loss is harder to spot
Latency is easy to notice because pretty much every test shows it. Packet loss is a bit sneakier, since a connection can look totally fine until a few percent of packets go missing and then everything starts to stutter.
TCP covers for this by resending the lost segments, but each resend costs another round trip. It also reads loss as congestion and slows down, so even 1% loss on a long-distance link can roughly halve your real throughput.
The most useful tool here is mtr on Linux or macOS, or WinMTR if you’re on Windows. It shows loss for each hop over a few hundred probes, and by the way, loss at a middle hop that doesn’t carry through to the last hop is usually just a router giving ICMP low priority.
Where the extra time from a proxy comes from
A proxy adds at least one more hop, and that hop sits somewhere physical in the world. If you send traffic from Berlin through an exit node in Dallas to reach a server in Frankfurt, you’ve added a trip across the Atlantic twice. Cloudflare’s page on what latency is says pretty much the same, that distance is the biggest factor and software can’t really get around it.
There’s also the cost of setting up connections. A client that opens a fresh connection through the proxy for every request pays for a new handshake each time, so turning on keep-alive fixes most of it.
Residential exits behave a bit differently from datacenter ones because they run on regular home ISPs. Response times of 150 to 300 ms are normal for them, while datacenter IPs are often under 50 ms, though they suit different kinds of work.
A simple order for troubleshooting
It makes sense to start in the browser. The Network tab in Chrome DevTools or Firefox splits every request into phases like DNS, connecting, TLS, waiting and receiving, and MDN’s guide to understanding latency explains what each one means pretty clearly.
A long waiting phase usually points to the server, and slow connecting or TLS phases point more to the network or the proxy. From the command line, curl -w with time_connect and time_starttransfer gives the same breakdown, so run it about 20 times with and without the proxy and the gap is your overhead.
And only after all that is it worth thinking about a bigger bandwidth plan, since you’ll usually find the slow part well before then.
What’s likely to change
HTTP/3 and QUIC already cut down handshake round trips, so as more proxies support them the setup overhead should shrink a bit. Distance isn’t going anywhere though, so where your exit node sits will probably stay the setting that matters most.
The people who sort out slow connections quickest usually aren’t the ones with better hardware. They’re mostly the ones who take the time to measure each part of the connection on its own before deciding what’s actually broken.