There are around 7,000 public Ookla servers listed here. In addition, if the public server is running more than one speedtests then it might not be able to give accurate and consistent measurements. Consequently, if the measured bandwidth is low, we don’t know what part of the connection is responsible. The path includes the WiFi (or wired network), the backhaul, the Internet connection between the edge of the infrastructure and the server, and finally the server. Since this test uses an Internet-based server the test path is the following: If these numbers are high enough (high enough being dependent on the user’s requirements) then you can at least know that the bandwidth between the user’s device and the Internet (where the Ookla server is) is not an issue.

You can ask the user that complained to go to, click the “Go” button and tell you what they see on their browser. This is the most well known and most commonly used speedtest. In addition, it can measure some other metrics as well such as latency and jitter.

It’s pretty straightforward how all of these speedtests work: a device uploads and downloads a large file to a server, and based on how long it takes, it calculates the connection bandwidth. In this post, we’ll cover five of them, their different features and how they can be used in different scenarios. There are a dozen similar tests (with every major TelCo provider having their own speedtest) and a number of free and paid mobile device apps available. There are many ways to do this, but the ‘quick and dirty’ way to test the network connection is to run a speedtest – such as the Ookla speedtest. But you are still tasked with proving that, “It’s Not the Network.”

If you have a few years’ experience in network troubleshooting, you know that when you receive a ticket from a user complaining about “slowness”, in most cases, it’s the user’s device or the application. (TL DR: this is a write up of the talk I gave at the Wireless LAN Professionals conference in February 2018.

Wifi speed ookla