A browser speed test and a sustained throughput run can rate the exact same VPN two completely different ways: one calls it fast, the other calls it barely usable, and only one of those numbers survives an actual video call. That gap is why proper vpn testing has to go past the big "Go" button, and why I run a small home lab setup dedicated to nothing but network latency and performance benchmarking. Burst numbers and sustained numbers rarely agree, and the tools that expose the difference are simpler than most people expect.
Browser Speed Tests vs. Sustained Throughput
Most people run one browser-based check, watch a needle swing, and call it done. Browser tools open several simultaneous connections to max out your pipe, which is a fine way to test raw ISP bandwidth and a poor way to test what a VPN tunnel does with a single steady stream of traffic. It's a little like shopping for a wifi router off the spec sheet — the box's theoretical top speed tells you nothing about how it performs once it has to fight through the actual walls in your house, and that distinction is the entire reason burst numbers and real usage diverge so often.
I gave up on trusting any single-click test after a stretch of running Tor Browser as my everyday browser, convinced it was the more honest privacy default. Ordinary pages took long enough to load that real work became impossible, and I went back to a normal setup within days. That failure taught me the same lesson bandwidth marketing does: a tool built for one job — anonymizing traffic through relays, or showing you a single peak number — will disappoint you the moment you ask it to do a different job, like getting real work done or holding a stable connection under load.
What iPerf3 Actually Shows You
iPerf3 sets up a direct client-server relationship instead of hitting some public test server that might be crowded — I run the server side on a small remote box and the client on my own machine, which strips out the browser overhead entirely. Callum Prentice, a friend from the Seattle Privacy & Security meetup, is the one who pushed me toward this in the first place. He's a DevOps engineer with zero patience for closed-source networking software, and he made the case that any tool hiding its methodology behind a shiny UI isn't worth trusting for a real number.
Numbers from that setup were revealing. Some services that looked fast in a browser test showed wild swings under iPerf3 — two hundred megabits for a few seconds, then a sudden drop to forty, then a spike back up. Developers call that jitter, and it's a bigger problem for video calls and screen shares than any peak-speed number will ever show you. It's also exactly why the Fastest WireGuard VPN for Home Lab Servers and Personal Tech Kits piece I wrote focused on sustained load instead of a single ten-second burst.
Tracing the Route with MTR
MTR combines ping and traceroute into one continuous readout of every hop your traffic takes, which is a lot more useful than either tool alone (background on how it works is on the MTR Wikipedia page). It answers a specific question: is the slowdown happening at your ISP, at the VPN's entry node, or somewhere in between?
A reader named Radek Soucek sends me his own benchmark spreadsheets every few months — meticulous CSVs, unprompted — because he moved from Prague and noticed that most published VPN numbers only ever cover US routes, ignoring what happens once traffic actually crosses the Atlantic. MTR is the tool that makes those cross-ocean routing costs visible instead of theoretical. One provider I tested had such a poor peering arrangement with my local ISP that traffic took a long detour through the middle of the country before reaching a server that was supposedly nearby, and no amount of encryption strength marketing changes a bad physical route.
Why an MTU Mismatch Looked Like a Bandwidth Problem
Packet loss on a connection that should have been solid sent me digging through logs for hours, and the actual cause wasn't server location or ISP bandwidth at all — it was a mismatch in the Maximum Transmission Unit setting, which was fragmenting packets on my router. Standard Ethernet caps out at 1500 bytes, but a VPN tunnel adds its own header on top of that: the User Datagram Protocol header alone is 8 bytes, the IPv4 header is another 20, and WireGuard's own overhead sits on top of that. Push a full 1500-byte packet through that stack and something has to give — the packet gets split, reassembled, and slowed down in the process.
Dropping the WireGuard MTU to 1420 left enough headroom for every header without triggering fragmentation, and the difference showed up fast — a four-gigabyte ISO transfer through a port-forwarded connection finished in well under eight minutes, a number that would have been unthinkable on the fragmented setup. Router CPU load dropped too, which made sense once the fragmentation stopped: the processor wasn't struggling with encryption, it was struggling with reassembling packets it should never have had to split in the first place.
Network Latency or Burst Speed: Which One Should You Trust?
Chase burst speed when the task is genuinely bandwidth-bound — a large one-time download, a big backup job, anything where total transfer time is the only metric that matters. Chase latency stability for everything else: video calls, SSH sessions, gaming, anything that breaks the moment ping jumps from twenty milliseconds to two hundred and back. A provider advertising eight hundred megabits sounds great, but almost nobody needs that ceiling to check email or stream a show — what actually ruins the experience is a ping graph that looks like a seismograph reading.
That distinction matters most on unstable connections, which is the whole premise behind Does a VPN Protect You from Public Wi-Fi Hackers? — on a shaky signal, a tunnel that degrades gracefully will always feel faster than one that chokes the moment a bar of signal drops, regardless of what either one claims on a spec sheet.
What These Numbers Don't Tell You
None of this tells you how a kill switch behaves the moment a tunnel actually drops, or whether split tunneling will let you keep a local printer reachable while everything else routes through the VPN. It says nothing about whether a provider's no-logs claim would survive a real audit, or whether paying extra for a dedicated IP is worth it for remote access into a work system. Protocol selection shifts every number in this piece by a meaningful margin, and a large file transfer over port forwarding behaves nothing like a video call even on the same connection. A browser proxy extension will pass a throughput test completely differently than a full system tunnel does, and running the VPN at the router level instead of a single machine changes the picture again. DNS leak protection is its own separate check, same with figuring out how your ISP classifies encrypted traffic before it ever reaches the tunnel. All of it comes down to scoping your own threat model first; the tools in this piece only answer the question of speed and stability, not which trade-offs are worth making for what you're actually trying to protect.