So I have some experience with this because I wrote the non-Fleash Speedtest for Google Fiber. I also have experience with this by virtue of being from Australi

So I have some experience with this because I wrote the non-Fleash Speedtest for Google Fiber. I also have experience with this by virtue of being from Australia. Let me explain. So Google Fiber needed a pure JS Speedtest for installers to verify connections. Installers were issued with Chromebooks, which don't support Flash and the Ookla Speedtest at the time used Flash. There's actually good reasons for this. It turns out figuring out the maximum capacity of a network link is a nontrivial problem. You can crash the browser with too much traffic (or just slow down your reported result). You can easily under-report speed by not sending enough traffic. You have to weigh packet sizes with throughput. You need to stop browsers trying to be helpful by caching things (by ignoring caching headers). There's a long list. So I did get a pure JS Speedtest that could actually run up to about ~8.5Gbps on a 10GbE link to a Macbook (external 10GbE controller over TB3). You learn just how super-sensitive throughput is to latency due to TCP throttling. This is a known and longstanding problem, which is why Google invested in newer congestion control schemes like BRR [1]. Anyway, adding 100ms of latency to a 1GbE connection would drop the measured throughput from ~920-930Mbps to a fraction of that. It's been a few years so I don't remember the exact numbers but even with adjustments I recall the drop off being like 50-90%. The author here talks about satellite Internet to Antarctica that isn't always available. That is indeed a cool application but you don't need to go this extreme. You have this throughput problem even in Australia because pure distance pretty much gives you 100ms minimum latency in some parts and there's literaly nothing you can do about it. It's actually amazing how much breaks or just plain sucks on that kind of latency. Networked applications are clearly not designed for this and have never been tested on it. This is a general problem with apps: some have never been tested in non-perfect Internet conditions. Just th eother day I was using one of the Citi-bike apps and it could hang trying to do some TCP query and you'd every now and again get "Connection timed out" pop ups to the user. That should never happen. This is the lazy dev's way of just giving up, of catching an exception and fatalling. I wish more people would actually test their experience when there was 100ms latency or if there was just random 2% packet loss. Standard TCP congestion control simply doesn't handle packet loss in a way that's desirable or appropriate to modern network conditions. [1]: https://cloud.google.com/blog/products/networking/tcp-bbr-congestion-control-comes-to-gcp-your-internet-just-got-faster https://cloud.google.com/blog/products/networking/tcp-bbr-co...