Why a VPN Slows You Down (and When It Doesn't)

“My VPN makes everything slower” is almost always true and almost never explained correctly. This guide breaks the slowdown into its three real components, tells you which one is actually responsible on your connection, and gives you a way to test it instead of guessing.

The three costs (encryption, the detour, the exit node)

Encryption is the cost most people blame first and the one that matters least on modern hardware. Every device sold in the last decade has dedicated silicon for AES encryption, and a VPN’s encryption overhead on that hardware is typically a rounding error — single-digit percentage points of throughput, not the halving or worse that VPN slowdowns often look like.

The detour is the real cost, almost always. Your traffic doesn’t go directly to its destination anymore — it goes to the VPN server first, then from there to the destination, then back through the VPN server, then back to you. That’s real physical distance added to every round trip, and distance costs time regardless of how fast either connection is. This is a geography problem, not a horsepower problem, and it’s the single biggest reason a VPN feels slow.

The exit node matters for a related but distinct reason: it’s not just distance, it’s also which network the exit node sits on, how well that network is provisioned, and how many other VPN users are sharing it at that moment. A congested or poorly-peered exit server adds its own latency and throughput penalty on top of the pure distance cost.

Which one is actually hurting you

For almost everyone, it’s the detour. A same-country exit node — one genuinely close to both you and your destination — typically adds only single-digit milliseconds of round-trip latency, often barely noticeable. A transatlantic exit node, or any exit node on a different continent from you and your destination, routinely adds 80–120ms or more, purely from the speed of light over that distance — no amount of better hardware or a faster VPN protocol changes that number, because it’s physics, not software.

Protocol differences, honestly

Modern VPN protocols (WireGuard and its relatives, in particular) are measurably more efficient than older ones, with less per-packet overhead and typically better latency characteristics under load. That’s real and worth knowing. But it’s a second-order effect next to the detour: switching protocols might claw back a few percent of throughput or a handful of milliseconds; switching to a genuinely closer exit server routinely claws back tens or hundreds of milliseconds. If you’re chasing VPN speed, the exit server location is where the leverage is.

When the slowdown is your VPN and when it is your line

One genuinely under-diagnosed cause worth knowing about: MTU and fragmentation. A VPN wraps your normal traffic in an extra layer of encapsulation, which makes each packet slightly bigger — and if that pushes a packet past the maximum size your connection’s path can carry in one piece, it has to be fragmented, which costs real throughput and can cost real latency if it’s handled badly along the path. This shows up as a VPN connection that’s inexplicably worse than the distance and encryption costs alone would predict, and it’s fixable by lowering the VPN’s MTU setting slightly — most VPN clients expose this, and it’s worth trying if a VPN feels unreasonably slow even to a nearby exit server.

Testing with it on and off

The cleanest way to know what your VPN is actually costing you is to run the same speed test with it off, then on, back to back, and compare the loaded-latency delta as well as the raw throughput — a VPN that’s adding bufferbloat of its own (some cheap or congested VPN services do) will show up as a much bigger delta with the VPN on than off, distinct from the flat, unavoidable latency it adds just from distance.

One honest caveat about that comparison: this site’s Speed Test measures to a nearby Cloudflare edge location, and a VPN changes which edge you’re measured against, because your traffic now leaves the VPN’s exit node, not your home connection. That’s not a flaw in the test, it’s just worth knowing — some of the difference you see with a VPN on isn’t the VPN’s overhead at all, it’s simply a different, and possibly farther or closer, measurement point. Comparing the same exit-node-off, exit-node-on test back to back is still the right way to isolate what the VPN itself is costing you; comparing your VPN-on number against a friend’s VPN-off number tells you very little.

Two more variables worth knowing about

Server load and time of day genuinely move VPN performance in a way they barely move a direct connection. A VPN exit node is shared infrastructure, and a popular server at peak regional hours can be measurably more congested than the same server at 4am — if your VPN speed seems to vary a lot test to test, this is a more likely explanation than anything about your own line. Most VPN apps let you switch servers within the same country; if one location tests slow, a different one on the same route is worth trying before assuming the VPN itself is the problem.

Split tunneling is the other lever, where it’s available: instead of routing every byte through the VPN, it routes only the traffic that actually needs the VPN’s privacy or access, letting everything else (streaming, large downloads, anything latency-sensitive that doesn’t need to go through the tunnel) take the direct, undetoured path. It doesn’t reduce the VPN’s overhead for the traffic that still goes through it, but it shrinks how much of your total usage pays that cost, which is often the more practical fix than chasing a faster exit server.

None of this is a case against using a VPN — the privacy and access reasons people use one are unaffected by any of the above. It’s a case for understanding what you’re actually paying in speed for it, and where that cost is coming from, so a genuinely slow VPN experience can be diagnosed instead of just endured.