Until some guy from New Zealand that doesn't have an edge in his country comes along. Don't actually apply this optimisation just because it's faster for you. It's probably slower for a lot of the rest of the world.

The "real world A/B test" I mentioned was part of ongoing performance test for a global top 20 site. I'm talking about millions of hits across all browser variants, OSes, markets, networks, etc. I can't cite the data directly because it's not public. You're right though that there will be plenty of cases where optimizations like this will be not work for some users. The most important thing, obviously, is to gather data from your own users and make the right choices based on them. Things change fast: new browser features; new user groups; new networks routes or proxies in your way. Results that were conclusive previously need to be retested regularly, including the following.

The particular scenario where we saw network-loading of resources consistently being faster was on first load of a frequently viewed page. In this scenario we found that loading certain scripts and images from cache (which we inferred to be physical disk because it was 'home page' activity) was slower for a significant portion of the experiment group than loading from the network. In this context loading from 'network' meant either a hot HTTP request to a CDN or inlining small images and scripts directly in the HTML on every single request.

As I mention above, it's worth regularly re-evaluating assumptions. I'd bet that the big CDN players have a huge presence in New Zealand and Australia, given the latency, cost of ingress and density of the actual population centres.

>Until some guy from New Zealand that doesn't have an edge in his country comes along. Don't actually apply this optimisation just because it's faster for you. It's probably slower for a lot of the rest of the world.

And who cares about the "guy from New Zealand"? You optimise to the markets/areas you target.

I think that's probably less bad these days, a lot of the problem with slow cached resources was due to IE6 and it's default cache size being a percentage of disk space with no cap, resulting in an excessively large cache (and not well indexed either), but later versions of IE do percentage with a cap so it doesn't get absurdly large.

This StackOverflow answer, "Numbers everyone should know", seems relevant here: http://serverfault.com/a/238534

Could you provide the data and test methods to backup that claim?