SerpApi.Org
What do you do when you run an internet speed test? Most of us just head to Speedtest by Ookla and take what it says at face value.
But what's going on under the hood isn't what we think, and it took firing up my own server to figure out where and how Ookla and other speed testing sites make your connection look good — and what's really going on.
Your speed test isn't wrong; it's just wildly optimistic
It's due to how Ookla and other speed tests are built
Ookla's server network is largely built and maintained by the ISPs themselves. The network operators, mobile carriers, universities, hosting companies, and others install Ookla's testing tools on their hardware, which is then listed as a testing point. This crowdsourced testing network is what makes Ookla such a useful speed-testing tool; you're never far from an Ookla-enabled server to run your internet connection against.
But it does mean that "nearest" server for most of us isn't a neutral, arbitrary point on the internet. It's often sitting on our own ISP's network, or about as close to it as physically possible. Testing against it tells you how fast your connection is to a best-case destination — not to the internet in general.
I spun up a speed test server to test this myself
With some extra testing software to keep track of data loss
To figure out what was really going on, I created a virtual private server (VPS) on Vultr running Ubuntu, then installed Docker and LibreSpeed. Like Ookla, LibreSpeed uses a similar browser-based client test that opens multiple simultaneous connections to saturate your internet connection.
I encountered a few issues along the way, it has to be said, and I'm acknowledging that renting a dirt-cheap VPS running in London is far from a lab-test scenario. It's shared virtual infrastructure, complete with shared CPUs, virtual networking, and the occasional noisy neighbor. That's exactly why I repeated every test multiple times rather than relying on a single result.
There was also an issue with some Ookla speed tests only using IPv6 servers, rather than IPv4. It's not necessarily a problem, as IPv6 is slowly "replacing" the older protocol, but given my VPS speed testing was all done using IPv4, I wanted it to be fair.
So, I disabled IPv6 on my Wi-Fi adapter, forcing Ookla to use IPv4, and saw some different numbers on my dash.
There is another part of this equation, too, which is that the raw throughput numbers don't give you the full picture. Alongside my Ookla and LibreSpeed tests, I also ran WinMTR, a free and open-source tool that basically combines the ping and traceroute commands into a single tool. It lets you see network hops in real-time, helping you identify where you're losing speed.
The results from WinMTR were equally interesting when compared to my speed testing results.
My speed test results were all over the shop
Multiple data points that I couldn't really explain
The speed tests I conducted gave me a hugely varied set of results, across both Ookla and LibreSpeed running on my VPS.
- My ISP's own server (Wildanet, hosted in London) averaged around 274 Mbps down and 98 Mbps up across three runs, with idle latency sitting at a flat 10-14ms.
- My own VPS came in much lower: 104-146 Mbps down and 71-113 Mbps up across seven separate runs. That's roughly 2x on download, with latency around 11.6-12ms across all tests.
However, it's not quite as straightforward as those figures make it sound. I had one VPS run hit 370 Mbps+, which is more than double any other speed I saw throughout all of my testing. I didn't do anything different, either. After that huge speed increase, I ran a bunch more tests, and everything else landed back in the 104-146 Mbps range.
Those results were obviously an anomaly, and I can't really explain why they happened. It could be some sort of cold-start burst before the connection settled, or something on my end that just happened to line up.
Bufferbloat also affected my speed tests
Something else that showed up in my testing data was bufferbloat, which can affect your network performance under load.
For example, at idle, my latency sits around 10ms. Under load, that jumped to an average of 175-210ms, spiking as high as 517ms at one point. That's bufferbloat: my router's buffers filling up under sustained traffic, with packets queuing up behind each other rather than actually being dropped.
It's a different issue from the on-net vs. off-net gap covered above, mind. Bufferbloat is about queuing and how that affects bandwidth, and it turned up regardless of which server I was testing against. But it's exactly the kind of thing a regular download/upload number won't show you, and it's actually a problem if you're on a video call or mid-game while something else on the network decides to upload a large file.
Where the paths go during testing tells you more than the speed
ISP networks vs. the broader internet
As said, this wasn't all about seeing what type of speed test is "better". I always knew the speeds between Ookla and LibreSpeed wouldn't match up; by how much was surprising. But it makes a bit more sense when you take the WinMTR results into account.
The Ookla testing, which largely uses preferential servers, showed roughly the same process each time: four to six hops, with the data staying inside my ISP's network.
Running the same testing while using LibreSpeed was a completely different story. WinMTR showed 12 hops, including the carrier-grade NAT assigned by my ISP, out for a trip through the London Internet Exchange, a real public interconnection point, before finally landing on my hosting provider's own network.
However, before you think the speed-test routing drama is done, I've got one more tantalizing bit of data for you to consider. Despite the eight extra hops and hitting a public exchange, my VPS's idle latency and Wildanet's Ookla speed test latency were almost the same, at 11-12ms and 10-14ms, respectively.
The upload ranges were also very similar, with the VPS's 71-113 Mbps aligning with Wildanet's 98 Mbps. So whatever advantage the on-net server has, it isn't showing up in latency or upload — it's almost entirely in download throughput. Those extra hops should, theoretically, cost some bandwidth, but that doesn't appear to be the case, and it only seems to matter in one direction.
Now, there isn't a thing wrong with the route the speed test took. In fact, it's much more realistic than Ookla's speed test, which is what's important here. It means that the gap boils more down to "How fast is my connection to my ISP" rather than "How fast is my connection to the internet."
Ookla's speed tests aren't lying, and I'll keep using it
Even with the testing above, it's not like Ookla is attempting to fleece you. It's not your ISP working to give you fake speed-testing data; what you see is still an accurate representation of your internet capabilities.
If you want to check your own connection the same way, it's not an expensive experiment. A cheap VPS, a LibreSpeed container, and a traceroute tool are all you need, and the whole thing costs pennies to run for the twenty minutes you'll actually need it (the VPS cost me literally $0.05, and that's after I left it running for a while by accident).
