Not bad.
EDIT: And they secured a fantastic domain.
Perhaps it's encrypted, or a Netflix promo piece.
Wouldn't there be copyright issues to use their actual streaming licences content?
The interesting traffic is not to fast.com.
It would be harder (though not impossible) if there is an actual capacity problem, and the bottleneck is outside of the ISP's network. For example insufficient peering capacity, which seems to be where most of the Netflix / ISP friction is.
That presumes they aren't fully emulating streaming traffic to test speed. Not only is this the correct thing to do from a video streaming company that wants to test connection speed for their services (the quantity and size of packets can affect the delivery through different mediums and devices), but it also makes it obvious when your ISP is quietly throttling your video streaming traffic.
Since it's a win-win in this respect, I would be surprised if this isn't exactly what they are doing.
It's not really a presumption, it's the actual facts on the ground. The actual benchmark file is served over HTTPS from, but there are still multiple simple ways to distinguish the current speedtest testcase from normal streaming.
Do you mind explaining the details you are aware of that lead you to think they are not emulating streaming traffic in at least some portion of their test (since they are testing multiple sessions and types of traffic)? I may have missed a portion of this article or some other source that outlined this.
It would fairly trivial to send sample content of actual video content for the test, and emulate a streaming client on the tester side, so I'm not sure how an ISP would distinguish traffic in that situation.
I agree, that in this case, where a separate domain was used, ISPs can use that to detect a speed test is likely. That said, I would like to note that every solution an ISP has to implement is much more expensive to any mitigation put forth by Netflix, as long as they want to hide what they are doing. If they aren't hiding it, well that's one of the reasons netflix is doing this, to inform customers what they are actually getting from their ISP, and let them make choice whether they like the current product they are using from their ISP (if they have a credible choice).
Ultimately if they're playing cat to Netflix's mouse how much does each mitigation strategy cost them relative to Netflix? I wonder if it's more cost effective to process that much traffic through shapers than it is to increase bandwidth between peers or allow Netflix to drop their boxes within their networks.
Like looking out for DNS queries for fast.com then handling traffic from that client differently for a period (such as the A record's TTL).
Then, I checked how much traffic speedtest.net is getting on SimilarWeb: wow, 150m visits per month, I didn't know that speed testing can be so popular.
Conclusion: Yes, it was right to buy this domain and if fast.com gets a large part of speedtest.net's traffic in the long term, Netflix has a neat free Marketing channel.
So I'm not enthusiastic at all.
That's nontrivially hard compared to the download portion, where they can use their existing CDN.
Sure -- they didn't build out a fully featured internet connection monitor. But what they have built is a pretty good tool, especially for diagnosing Netflix or last-mile performance.
Apparently they have slow.com as well.