Where the Slowdown Comes From When You Connect a VPN
A tunnel adds work and distance, so yes, a VPN costs something. The useful question is not whether but where: five distinct mechanisms are at play, they affect different things, and they are separable. One makes pages feel hesitant, another caps large transfers, another produces failures that look nothing like slowness at all.
This is the mechanical account rather than a measurement exercise. If what you want is a figure that applies to your own line, the procedure for producing one — and the reason no published figure can substitute for it — is in nobody can sell you the fastest VPN.
The path is longer, and it is not straight
Your traffic now goes to the VPN server first and reaches its destination from there.
That is at minimum a detour, and often a substantial one. A request that would have travelled to a nearby content server may now cross a continent to the VPN server and then come back. Every reply retraces it. Distance imposes a floor on how quickly a round trip can complete, and nothing in the tunnel’s design can go under that floor.
Detours also do not follow the shortest geographic route: the networks in between are chosen by routing policy rather than by distance, so the real path can be considerably longer than a map suggests. It is directly observable — comparing the route to a familiar destination with and without the tunnel shows the shape of the detour and where the hops go, the exercise in what a traceroute shows.
The effect concentrates on anything involving many small exchanges — page loads, interactive sessions, request-heavy applications. A single sustained transfer notices distance much less, because its round trips overlap.
Every packet gains a header
Encapsulation means your original packet is wrapped inside another one, and the wrapper occupies space.
The wrapper carries the outer addresses, the tunnel’s own bookkeeping, and the integrity data the encryption produces. That space comes out of the packet you were going to send anyway, so each one carries slightly less of your data — a modest, permanent tax, since the same transfer now takes a few more packets.
The second consequence is worse: the wrapper interacts badly with a limit further along the path.
Packet size is where it stops being modest
Every network link has a maximum packet size, and the wrapper can push packets past it.
If your device builds a full-sized packet and the tunnel then wraps it, the result may exceed what some link along the path will carry. Three things can happen. The oversized packet gets split into two, which multiplies overhead and makes loss more damaging, since losing either half loses the whole. Or it is discarded with a notification back to the sender, which adjusts and continues — the intended behaviour. Or it is discarded silently, because something on the path suppresses those notifications, and then the sender keeps retrying a packet that can never arrive.
That third case is worth recognising, because it does not present as general slowness. It presents as small requests succeeding while large ones hang, or some sites loading and others stalling partway. The fix is a packet-size setting rather than a different server, and it is worth ruling in before treating the problem as bandwidth — the broader ordering is in narrowing down why your VPN is not working.
The exit server is a shared resource
Your traffic is competing with everyone else connected to the same machine, on the same uplink.
A VPN server has finite processing capacity for encryption and a finite connection to the internet, and both are divided among current users. When a popular server is busy, everyone on it is affected at once, which is why a slowdown can appear and disappear over an evening without anything on your side changing.
It is also the mechanism most under your control: moving to another server moves you to a different set of neighbours and a different uplink. If that changes things markedly, capacity was the constraint, and nothing about your device needs attention.
The protocol, and where it runs
Different tunnel protocols do different amounts of work per packet and behave differently when a network is unhelpful.
Some are lean, with small headers and quick handshakes. Some can be told to disguise themselves as ordinary web traffic to get through restrictive networks — which works, and costs more, because it adds another layer of wrapping and can move the tunnel on top of a transport that already handles retransmission. One reliable transport inside another means two systems reacting to the same lost packet, and the interaction is not in your favour.
Where the tunnel runs matters as much as which protocol it uses. A router handling encryption for a whole household is often the weakest processor in the chain, and it can become the ceiling for every device behind it — one of the differences set out in why a router VPN behaves differently from an app.
Your own device is doing work too
Encryption is cheap on current hardware and not free on all of it.
Modern processors have dedicated instructions for the ciphers in common use, so on a recent laptop or phone the cost is unremarkable. On older hardware, low-power devices, and small routers without them, the processor can genuinely become the limit — the signature being a ceiling that does not move when you change servers.
Matching a symptom to a mechanism
The word “slow” gets attached to three symptoms with three different causes, and mixing them up is why the topic stays confusing.
A pause before anything happens, then a normal load. That is name resolution, not the tunnel. A resolver at the far end is further away than the one your router advertised, so cold lookups take longer while cached ones are unaffected — the setting behind it is in what your VPN’s DNS setting changes.
Interaction that lags continuously. Round trips, which means path length. Distance and hop count, not capacity.
A ceiling that only appears on large transfers. Capacity, packet size, or processing — the server’s share, fragmentation, or your own device. Distance affects this far less than people assume.
Narrowing it to one mechanism
Three comparisons, none of which requires a number.
Compare the route with and without the tunnel: a long detour puts distance in play. Compare two protocols in the same client on the same server: a clear difference points at protocol overhead, or at the network interfering with one of them. Compare two devices on the same network and server: if one is markedly worse, that device’s processing is the limit rather than anything at the far end.
Each comparison eliminates something, and between them they usually name the constraint — which is what tells you what to change: a nearer server, a different protocol, a packet-size setting, or a tunnel that runs somewhere other than on a router.