Your download is fast, so why does every click feel slow?

Downloading a large file quickly and then finding every click slow is not a contradiction. Capacity says how much can move per second; round-trip time says how long an exchange takes before anything useful happens. Improving the first does nothing for the second, and the second is what a person notices while typing, clicking or talking. Measure the complaint rather than the connection.

Fast file, slow click: two different numbers

A bulk transfer keeps data in flight continuously, so it can report a healthy rate even when each individual request waits. Many benchmarks also open several connections at once, which raises the aggregate figure while a single request remains slow. The two results are compatible, and quoting the higher one to a user who is complaining about lag is how trust is lost.

A page load is a chain of small exchanges: name resolution, connection setup, a request, a response, then dependent requests. Each step pays the round trip again, so a path with high delay feels slow even when it has plenty of capacity.

The tunnel adds its own travel and processing, and the route matters more than the label on a map. Two exits in the same country can have very different paths to one destination. A twenty-millisecond difference is enough to change how a page feels, even though it barely moves a throughput number. That is why exit selection should follow a latency sample rather than a flag icon.

Measure the complaint, not the connection

Pick the measurement that matches the sentence the user said. A slow download needs a sustained rate in the right direction; a laggy call needs that application's own statistics; a page that starts slowly needs resolution and setup timings.

ping -c 20 10.60.0.5
curl -sS -o /dev/null -w 'ttfb=%{time_starttransfer} rate=%{speed_download}\n' https://files.plant.example/1gb.bin
iperf3 -c 10.60.0.5 -t 10 -P 4

The first command gives a round-trip sample to a host that responds predictably, the second reports time to first byte and sustained rate for one connection, and the third measures aggregate throughput with four parallel streams. Run them against the same destination at the same time of day, because comparing a morning sample with an evening one produces a story rather than a measurement.

Keep the destination fixed when comparing exits. Changing both the server and the tunnel turns one variable into two, and the result cannot tell you which mattered. Run each exit at least three times as well, because a single sample often lands during a routing change or a noisy minute. The median is more useful than the best case.

Treat ICMP as a clue rather than the answer. A responding host may handle echo requests on a different path than the one your application uses, and one lost reply is not evidence that every application is losing packets.

Loaded latency is a queueing problem

The pattern that confuses people most is a connection that feels fine when idle and unusable during a backup. That is queueing, not capacity. A saturated uplink builds a buffer in front of every other packet, so a keystroke waits behind a chunk of the upload.

ping -c 20 10.60.0.5 &
iperf3 -c 10.60.0.5 -t 20 -R -b 20M

The first command samples latency in the background while the second saturates the reverse direction. If the ping times jump during the transfer and recover afterwards, you have reproduced bufferbloat rather than discovered a routing fault. The fix is usually a queue management setting, a lower background rate, or moving the bulk transfer off the interactive path.

Reducing optional background traffic often helps more than switching exit country. It is also cheaper, reversible and testable in a minute. Schedule large uploads outside working hours if the queue cannot be managed, and rate-limit them if they must run during the day. A queue management setting is the better fix when the router supports one.

Change one thing and compare like with like

For high idle delay, compare exits while holding the destination fixed, then compare routes for the best candidate. For low steady throughput, look at capacity, server load and client processing instead, because those are different limits.

Write down what you measured, against which destination, at what time and with which settings. A comparison without those four facts cannot be repeated, and the next person will start from zero.

Then match the tool to the claim in the ticket. "Slow internet" is not a measurement; "first byte took 900 ms to this host while throughput was fine" is one, and it points directly at delay rather than capacity.