As much as ads are annoying, this has nothing to do with the article. One man's bloat is another man's content. No need for this nag to be top comment on HN for an article about why data isn't moving at the speed of light.
The code in tracking scripts varies between "short and elegant" to "massive and slow code". There is also a piece of json where the tracker thinks it is necessary to call 10 other trackers: See for example http://ib.adnxs.com/async_usersync?cbfn=AN_async_load : AN_async_load([ {"url":"http://cm.g.doubleclick.net/pixel?google_nid=appnexus&google..., "tagtype":"img"}, {"url":"https://ib.adnxs.com/getuid?https%3A%2F%2Fcm.g.doubleclick.n..., "tagtype":"img"}, {"url":"http://c.bing.com/c.gif?anx_uid=xxxx&Red3=MSAN_pd", "tagtype":"iframe"}, {"url":"http://odr.mookie1.com/t/v2/sync?tagid=V2_4265&src.visitorId..., "tagtype":"img"}, {"url":"http://match.adsrvr.org/track/cmf/generic?ttd_pid=appnexus&t..., "tagtype":"img"}, {"url":"http://pixel.rubiconproject.com/tap.php?v=4894&nid=1986&put=..., "tagtype":"img"}, {"url":"http://sync.mathtag.com/sync/img?mt_exid=13&mt_exuid=xxxx&re..., "tagtype":"img"} , {"url":"http://p.rfihub.com/cm?in=1&pub=345&userid=xxxx", "tagtype":"img"}, {"url":"http://t.mookie1.com/rsp?dnv=[TIMESTAMP]&rurl=//ib.adnxs.com..., "tagtype":"img"}, {"url":"http://t.wayfair.com/a/vendor_sync/user?vendor_id=1&uid=xxxx..., "tagtype":"img"} ]);
The slowness that we experience is from delays caused by calling scripts that call scripts that call scripts, processing large pieces of javascript and network latencies. edit: and server latencies.
Their page has a high number of requests primarily because they do not bundle their javascript, CSS, or icons.
I see 95 requests that I see without adblocking, and about 20 of those requests are javascript coming out of their own WordPress instance. They're using 2 different full icon libraries and adding at least 5 more icons not contained in either.
Think about it. If you include a gigantic library in a compiled language, but only use 3 of its features, the rest of the library doesn't make it into your final program. Only those three features that you used do, because that's the linker's job. It takes only the features of a given library that are actually used for space efficiency reasons, and removed anything unneeded.
This is possible for JavaScript, but common language usage patterns work against this goal. If you're going to use a clientside library that's fine, but you should ship only the small fraction of it that your code actually calls into, not the entire honking library, 90% of which goes untouched by the client for every user.
Point here is, I agree with you, but this is a difficult problem to solve. You're asking a large number of frankly inexperienced programmers to deviate heavily from most JavaScript tutorials, and worse, most example code included in the documentation of most large frameworks.
The equivalent for dynamic languages is tree shaking, and is a harder or impossible problem depending on the language. When you can do something like the following in JavaScript, how do you determine what's dead or alive?
var fn = document.getElementById("function").value;
var input = document.getElementById("input").value;
var output = functions[fn](input);
document.getElementById("output").value = output;
Ignore if it can be detected or not, we'll pretend that the author has to certify that they followed your subset and didn't do X, Y, or Z. If they disobeyed your rules then all bets are off and the result is undefined.