“Why is my internet so slow with a VPN on?” is one of the most common questions we receive, and the honest answer is more nuanced than a single number. Some speed loss is unavoidable — you’re adding encryption overhead and routing through an intermediary server — but the amount varies enormously depending on protocol, server choice, and even your own hardware. This deep dive breaks down the actual mechanics of VPN speed loss using data from our lab testing, and shows exactly where the biggest gains can be recovered.
The Basic Tradeoff: Why Some Slowdown Is Inevitable
A VPN works by wrapping your normal internet traffic inside an encrypted tunnel and routing it through a remote server before it reaches its final destination. This process introduces three unavoidable sources of overhead:
- Encryption/decryption processing: Your device and the VPN server both need to encrypt and decrypt every packet, which takes processing time.
- Additional routing distance: Instead of your traffic going directly to a website or service, it first travels to the VPN server, then onward — an extra hop that adds distance and therefore latency.
- Packet overhead: Encryption adds extra bytes to every packet for headers and authentication data, slightly reducing the “useful” data-carrying capacity of your connection.
None of these factors are flaws in a specific provider — they’re structural to how VPNs work. What differs between providers is how efficiently they’ve engineered around these constraints.
Protocol Comparison: Where Most of the Difference Comes From
The single biggest lever affecting VPN speed is the underlying protocol. We ran identical throughput tests switching only the protocol, with every other variable (server, time of day, hardware) held constant.
| Protocol | Avg. Speed Retention | Added Latency | CPU Overhead |
|---|---|---|---|
| WireGuard | 91% | +7ms | Low |
| IKEv2/IPsec | 85% | +11ms | Low-Medium |
| OpenVPN (UDP) | 78% | +16ms | Medium |
| OpenVPN (TCP) | 65% | +27ms | Medium-High |
| SSTP | 61% | +31ms | High |
WireGuard’s lean, modern codebase (roughly 4,000 lines of code compared to OpenVPN’s much larger footprint) translates directly into lower processing overhead and, in turn, higher real-world speeds. OpenVPN over TCP in particular suffers from a well-known networking issue called “TCP meltdown,” where reliability mechanisms in both the outer VPN connection and the inner application traffic interact poorly during any packet loss, compounding delays rather than simply adding them.
Distance and Routing: The Physics You Can’t Avoid
No amount of software optimization can overcome the speed of light. Data traveling from Seoul to a VPN server in New York and back adds real, physical latency that no protocol improvement can eliminate — typically in the range of 150-200ms round trip just for that added stretch of the journey. Our regional testing consistently showed that server distance was the single strongest predictor of both latency and, to a lesser extent, throughput loss. This is why choosing the nearest reasonable server location remains the most effective speed optimization available to any user, regardless of which provider or protocol they’re using.
Server Load: The Hidden Variable
A VPN server is a shared resource. Every additional user connected to the same physical or virtual server competes for the same finite bandwidth and processing capacity. We logged connection counts alongside speed results where providers exposed that data, and found a clear negative correlation between concurrent user count and available throughput per user. This explains why the exact same server, on the exact same provider, can feel noticeably faster at 6am than at 9pm — nothing about the technology changed, only the number of people sharing it.
Encryption Cipher Strength vs. Speed
Some users assume that stronger encryption automatically means slower speeds, but modern hardware has largely closed that gap. AES-256, the current industry standard, benefits from hardware acceleration (AES-NI) built into virtually every modern CPU, meaning the encryption step itself adds only a fraction of a millisecond of processing time on both ends of the connection. ChaCha20, the cipher WireGuard uses by default, was specifically designed to run efficiently even without hardware acceleration, making it a strong choice for mobile devices with less powerful processors. In our testing, cipher choice alone accounted for a much smaller speed difference than protocol or server distance — typically under 3% — meaning users shouldn’t sacrifice meaningful speed just to use a weaker cipher.
Multi-Hop and Obfuscation: Understanding the Tradeoff
Privacy-focused features like multi-hop (routing through two VPN servers instead of one) and obfuscation (disguising VPN traffic to look like regular HTTPS traffic) both add measurable overhead by design. In our tests, enabling multi-hop routing reduced throughput by 25-40% compared to a single-hop connection on the same provider, which is the expected cost of encrypting and routing your traffic twice. Obfuscation added a smaller but still noticeable overhead, typically 5-12%, since it requires additional processing to disguise packet signatures. These features exist for a reason — bypassing VPN blocking or adding an extra layer of anonymity — but they should be treated as deliberate, situational tradeoffs rather than left permanently enabled if raw speed is your priority.
Local Hardware and Network Conditions
Not every slowdown is the VPN’s fault. We ran a control test isolating local hardware variables and found that older routers, especially those without hardware-accelerated VPN passthrough, could bottleneck a connection well below what the VPN service itself was capable of delivering. Similarly, Wi-Fi congestion from neighboring networks, outdated Wi-Fi standards (802.11n versus modern Wi-Fi 6), and even an overloaded home network with many connected devices all showed up as “VPN slowness” in casual testing, despite the VPN performing normally when measured on a clean, wired connection.
Real-World Test Data: Isolating Each Variable
To confirm the theory held up in practice, we ran a controlled experiment changing exactly one variable at a time against the same baseline connection, holding everything else constant. Switching only the protocol from OpenVPN (TCP) to WireGuard recovered an average of 26 percentage points of speed retention on identical hardware and server locations — by far the single largest gain available from any one change we tested. Switching only the server from a distant, popular location to the nearest available lightly-loaded server recovered an average of 14 percentage points. Disabling multi-hop, where it had been enabled, recovered an average of 22 points. Each of these changes is available within a few taps in virtually any modern VPN app, which is why we consistently point users toward settings adjustments before assuming a provider itself is simply “slow.”
A Note on Router-Based VPN Performance
Configuring a VPN directly on a router, rather than per-device, introduces its own speed considerations worth understanding separately. Consumer routers vary enormously in raw processing power, and unlike a modern phone or laptop CPU, many budget router chipsets lack hardware acceleration for VPN encryption. In our testing, a mid-range router handling WireGuard encryption for an entire household’s traffic showed measurably more throughput loss than the same connection tested on a single device with a dedicated CPU. If you’re running a VPN at the router level for whole-home coverage, checking your specific router model’s rated VPN throughput — not just its advertised Wi-Fi speed — is an important, often-overlooked step before assuming your VPN provider is the bottleneck.
Practical Steps to Minimize Speed Loss
- Use WireGuard whenever available. It consistently outperformed every other protocol in our testing with minimal tradeoffs.
- Pick the nearest server for the content or service you need, rather than defaulting to a far-away “fastest” recommendation from the app.
- Avoid multi-hop and obfuscation unless you specifically need them, since both introduce deliberate, measurable overhead.
- Test on a wired connection before troubleshooting your VPN, to rule out local Wi-Fi or router bottlenecks.
- Restart your router periodically, especially older models, since accumulated processing load can degrade VPN passthrough performance over time.
- Check server load indicators if your provider’s app displays them, and switch away from heavily congested servers.
Common Misconceptions About VPN Speed
A few myths persist even among fairly experienced users. The first is that a more expensive subscription automatically means faster speeds — in our broader testing this year, price correlated only weakly with performance once you excluded free tiers, since infrastructure investment doesn’t always track subscription cost in a straight line. The second is that connecting to a VPN server in a country with generally fast national internet (such as South Korea or Singapore) guarantees fast speeds for the connecting user, when in reality the relevant factor is the route and distance between your own location and that specific server, not the host country’s general internet reputation. The third misconception is that a VPN kill switch or additional security features inherently slow down a connection — in our testing, kill switches added no measurable throughput impact, since they simply monitor the connection state rather than processing traffic.
Conclusion
Some VPN speed loss is simply the price of the added encryption and routing — that part isn’t going away. But our testing makes clear that the majority of the noticeable slowdown people experience comes from avoidable factors: outdated protocols, distant server choices, overcrowded servers, and unnecessary privacy features left switched on by default. Address those variables, and a modern VPN running WireGuard against a nearby, lightly-loaded server can feel almost indistinguishable from a direct connection for the vast majority of everyday tasks.