Some VPN slowdown is normal. Learn the four causes — distance, tunnel overhead, encryption and server load — and how to measure your own loss.
You switch the VPN on and pages feel heavier, video buffers, a call stutters. Is that normal, or is something wrong? Some slowdown is expected, because a VPN really does change the path and the packets. But a big loss usually points at one specific cause — most often a far-away or overloaded server — rather than "the VPN" as a concept. Here are the four causes, and a way to measure what you actually lose.
Key Takeaways
- Four things slow a VPN connection: a longer path via the VPN server, extra header overhead per packet, encryption work on your device or router, and the load on the server and its upstream.
- There is no universal "normal" percentage. Any single number quoted for all VPNs would be invented; your loss depends on your server, protocol, device and ISP.
- Latency and throughput are separate losses. Distance mostly hurts latency; overhead, CPU and server load mostly hurt throughput.
- Measure it yourself: same speed-test server, VPN off then on, several runs each, and compare latency and throughput separately.
- A VPN changes your IP, not your browser fingerprint — and it can make some sites suspicious of you.
1. Extra distance: the detour through the VPN server
Without a VPN, your packets go from your device to the site by whatever route your ISP picks. With a VPN, they go to the VPN server first and only then to the site, and the reply comes back the same way. If the server sits in another country, that detour adds round-trip time that no software can remove: signals in fibre only travel so fast, so distance sets a floor on latency.
This matters more than people expect, because throughput on a single connection depends on latency too. A TCP connection can only keep so much data in flight before it must wait for acknowledgements, so the same bandwidth delivers less per-connection speed when the round trip is longer. A nearby server often feels much faster than a distant one on the same plan.
2. Encapsulation overhead and the MTU problem
A tunnel wraps each of your packets inside another packet. That outer wrapper — a new IP header, a UDP or TCP header, and the VPN protocol's own header and authentication data — takes space, so each packet carries a little less of your actual data. The effect on speed is usually modest in a healthy setup.
The sharper problem is the MTU (maximum transmission unit, the largest packet a link will carry). Ordinary Ethernet paths commonly allow 1500 bytes, but the tunnel's wrapper has to fit inside that too, so the usable size inside the tunnel is smaller. If a packet is too large, it must be fragmented or dropped. RFC 4459 describes these MTU and fragmentation issues with in-the-network tunneling. When a device on the path silently discards oversized packets and the sender is never told, connections can stall or crawl: small requests work, large transfers hang, and some sites load only halfway. This is the classic "blackhole" failure.
Modern stacks try to find the working size automatically. RFC 8899 defines packetization-layer path MTU discovery, which probes for the largest size that actually gets through instead of relying on error messages that firewalls often block. For a readable walk-through of how path MTU discovery works and breaks in practice, see Cloudflare's explainer. If a VPN is strangely slow only for certain sites or large downloads, a too-high MTU setting is a classic suspect, and lowering the tunnel MTU in your client is a common fix.
The transport the tunnel itself runs over matters too. Most modern VPN protocols, such as WireGuard and OpenVPN in its default UDP mode, carry your traffic over UDP. Some clients fall back to a TCP mode to get through restrictive firewalls, and then your own TCP connections run inside another TCP connection. When packets are lost, both layers retransmit and back off at once, which can turn a little loss into a large slowdown. If your client offers a choice, UDP is usually the faster one.
3. Encryption costs CPU
Every packet is encrypted before it leaves and decrypted when it arrives. On a modern laptop or phone this is cheap, and many CPUs have hardware help for common ciphers. On an old phone, a low-power router running the VPN client itself, or a busy single-core device, the cryptography can become the bottleneck, capping throughput well below your line speed. A tell-tale sign: your CPU spikes during a transfer and the speed never gets close to the plan's rate even on a nearby server.
4. Server load and the provider's upstream
The VPN server is shared. If many people use it at once, or its connection to the wider internet is congested, you share what is left. The provider's own route to the destination also matters: a server that is close to you but badly connected to the site you want can still be slow. This is why switching to a different server, even in the same city, sometimes changes the speed dramatically.
How much slowdown is normal?
Treat any universal figure with suspicion. What is normal for you is something you can measure in a few minutes:
- Pick one test and keep it fixed. Use the same speed-test server and the same device, on the same network, so only the VPN changes.
- Test with the VPN off, then on. Use BrowserInsight's network speed test, which reports download, upload, latency and jitter from your browser. Run each state at least three times; one run is a snapshot, not a verdict (see why speed test results keep changing).
- Compare latency and throughput separately. Higher latency with similar download points to distance. Much lower download with modest latency change points to overhead, CPU or server load. M-Lab's open NDT test is another independent way to cross-check throughput.
- Change one variable at a time. Try a nearer server, then a different protocol (or UDP instead of TCP mode), then a lower MTU. Re-test after each.
If you are unsure what the numbers mean, Internet speed metrics explained covers bandwidth, latency and jitter, and upload vs download speed explains why the two directions often differ, so compare each one separately. If calls get worse specifically when someone else is using the connection, that is probably not the VPN at all but bufferbloat, and if quality is choppy rather than slow, see jitter and packet loss.
Be aware of what the speed test does and does not tell you. It measures the path between your browser and this site's edge, so it shows how fast your connection is with and without the VPN. It does not detect the VPN and it does not measure your MTU.
Can a VPN make things faster?
Occasionally. If your ISP throttles certain traffic, or its default route to a destination is poor, a tunnel can bypass the problem and the result can improve. That is possible, not common, and you should only believe it if your own before-and-after test shows it.
A note on privacy
A VPN changes the IP address sites see; it does not change your browser fingerprint, and some sites treat VPN addresses with suspicion. For what each tool actually hides, see privacy tools compared, and for how sites spot VPN traffic, see how websites detect VPNs. To see what a site sees once you are connected, run the VPN check.
Frequently Asked Questions
Why is my VPN so slow all of a sudden?
Most sudden changes come from the server: it became crowded, or its upstream is congested. Reconnect to a different server and re-run your before-and-after test before changing anything else.
Does a VPN always reduce speed?
Usually it adds some latency, because the path is longer. Throughput loss can be small on a nearby, lightly loaded server and large on a distant or overloaded one.
Why do small pages load but large downloads hang?
That pattern often points to an MTU problem: small packets pass, large ones are dropped. Try lowering the tunnel's MTU setting.
Is a wired connection better with a VPN?
It removes Wi-Fi variability from the test, so your VPN comparison is cleaner. It will not fix a distant server.
Conclusion
A VPN slows you down for four reasons: distance, tunnel overhead, encryption work and server load. How much depends on your setup, so measure it with the VPN off and on, separating latency from throughput. Then change one thing at a time — usually the server first.
