Nobody Can Sell You the Fastest VPN: Measure Your Own Instead

A “fastest VPN” claim is not a lie so much as a category error: it attaches a property of one network path, at one moment, to a company name. You cannot check it from where you are sitting, and neither can the next reader, because the thing being described is not a feature of the service — it is the outcome of your own access link, the route between you and one particular exit, and the load on that exit while you were watching. The only speed result that means anything to you is one you produced yourself.

This page gives no figures and names no service. It explains why the claim format is empty and sets out a way to get an answer that applies to you.

Why the claim cannot be checked from your chair

Three separate things make a published speed figure unfalsifiable in your hands.

It describes a path you will not use. A measurement is taken from a specific network, to a specific exit, over whatever route existed between them at the time. Change any of those and the number changes. Your access link, your provider’s routing, and the exit you happen to pick are all different, so there is nothing for you to reproduce or contradict.

It is a single sample of a varying quantity. Network performance moves through the day, and it moves for reasons that have nothing to do with the service — your neighbours, your provider’s busy hour, the state of the internet between two cities. A number with no distribution behind it cannot be verified or refuted; it can only be repeated.

It has usually been produced by, or on behalf of, the party being measured. Even setting motives aside, whoever runs the test picks the conditions, and the conditions are most of the result.

Add these together and you get a claim that survives contact with any reader, because no observation could ever prove it wrong. That is the defining property of a statement not worth acting on, and it is why performance sits firmly in the perishable half of what you can learn about a provider — see which facts about a VPN provider are still true next year.

“Fast” is three different quantities

Half the confusion in this subject comes from one word standing in for measurements that do not move together.

Throughput is how much data you can shift per second in bulk — large downloads, video, backups. It is the quantity every advertisement is about and the one that matters least for how a connection feels.

Round-trip delay is how long it takes a packet to reach something and get an answer back. It governs how responsive everything feels: page loads, typing into a remote session, voice calls. A tunnel usually adds to it, because your traffic now visits an intermediate place before continuing.

Variability is how much either of the above wobbles from second to second. Steadiness is what makes a call intelligible or a remote session usable, and a connection with modest but consistent numbers is more pleasant than one that is fast on average and erratic in practice.

A service can look strong on the first and be poor on the other two. Decide which of the three your actual work depends on before you measure anything, because the test you run is different for each.

What actually sets your result

These are the variables in play, listed so you know what you are holding constant. The mechanics of why a tunnel costs you anything at all belong to does a VPN slow down your internet; the point here is simply that almost none of them are properties of the brand.

• Your own access link’s ceiling. No tunnel makes a connection faster than the line it runs over, and if you are already near that ceiling the tunnel cannot be blamed for it.
• How far away the exit is, and how your provider gets there. Distance costs round-trip delay directly. The route is visible to you, and what a traceroute shows before and after you connect is how to look at it.
• How busy that exit is, and how many people share it. Capacity is finite and shared, which is why the same exit behaves differently at different hours.
• Encapsulation overhead and packet size. Wrapping traffic adds bytes and can force awkward fragmentation, which shows up as a penalty out of proportion to the extra bytes.
• Which protocol is in use, and what is doing the work. A phone, a laptop and a router have very different capacity for encryption, which is one reason the same service performs differently depending on where the tunnel lives — see why a router VPN behaves differently from a VPN app.
• The time of day, at both ends. Congestion is a schedule, not a constant.

A procedure that produces an answer about you

Nothing here needs special tools, and the whole thing fits in an evening.

1. Measure your baseline first, with no tunnel. Everything afterwards is a comparison against this, and without it you have no idea what you are attributing to the tunnel.
2. Fix your target. Use the same destination throughout, ideally one that resembles what you actually do rather than a purpose-built speed test.
3. Take several readings, not one, and note the spread rather than the best result. The spread is the finding.
4. Repeat at a different hour, including your household’s busy period. If the two sets disagree, the hour matters more than the service does.
5. Test more than one exit, including a near one and a far one. This separates distance from capacity.
6. Measure round-trip delay separately from bulk throughput, because they can move in opposite directions.
7. Then use it for a day on the work you actually do. The subjective result is not less valid than the numbers; it is the thing the numbers were a proxy for.
8. Write down your conditions. Which network, which exit, what time, which protocol. A result without its conditions is exactly the kind of claim this page is about.

What would make a published figure worth reading

For completeness, since some careful work does exist: a performance claim is usable when it states where it was measured from, to which exit, on what kind of access link, at what times, how many samples were taken, what the spread was, and when. A figure carrying all of that is a genuine data point about somebody else’s situation, from which you might infer something about yours. A figure carrying none of it is decoration.

Why no fastest service is identified here

We have not run these services, so we hold no measurements of our own, and a speed ranking assembled from other people’s pages would be a stack of unverifiable single samples presented as a comparison. That is worse than saying nothing, because a number implies a method, and there would be no method.

There is also a structural reason no honest page could do it: the fastest service for you depends on facts about your line and your route that the author does not have. Anybody claiming to know it in advance is claiming knowledge of your network, which they do not possess. The method above is the part that transfers; the answer is not.