I think this is likely to be related to the way different browsers implement time.
In an effort to improve security, browsers reduce fidelity & accuracy on results from the `performance.now()` timer methods. If you attempt to call `performance.now()`, and then call it again within 100 microseconds, your second result isn't guaranteed to be in the future compared to the first result.
If you're implementing a speedtest feature, you'd likely run `performance.now()` iteratively as your high-resolution-timer, and compare that to the number of bytes downloaded. Browsers that perform more significant coarsing will return worse metric-per-second results in that scenario.
I've ran it multiple times in Chrome only and got vastly different results just there, from 200 to 600 down on a 500 connection. Must be heavily dependant on moment-to-moment network conditions I guess, to the point where it's nigh useless.
Yes, the bandwidth test is so short that I'm not surprised it gets inconsistent results. I'd wager the speedtest.net being longer was not decided for fun, but to get more consistent results.
edit: Now I realize that the later tiny-small-medium filesize downloads also add to your above-the-fold download performance, so the results of the initial warm-up test are discarded later.
I have a 500/500M connection and on the same computer Chrome gives 465/364 and Firefox has 311/303M.
EDIT: this was on Linux/intel.
On Mac M1Pro it Chrome/FF/Safari all get pretty much the same numbers.
Both computers have wired ethernet.