When your au­di­ence is most­ly n00b front-end strug­glers, as a medi­um ex­ist­ing be­cause of pub­li­ca­tions and not so­lu­tions it's per­fect­ly rea­son­able to waste every­one's time adding an­oth­er chap­ter to the cir­cle jerk that do­ing some Bos­ton Globe web­site ap­par­ent­ly was. Other­wise it makes no sense, for the fol­low­ing rea­sons:

There is no re­li­able way to de­ter­mine the amount of band­width a user is will­ing to spend on a sin­gle re­source. Be­cause screen size is all we've got to query in some mo­bile cu­ri­ous way that doesn't mean it's us­able or ef­fi­cient to do so. So it's some Spiel­erei to pre­pare for the mag­ic event when there is an API that we can use to de­ter­mine the band­width on a de­vice? No, be­cause mo­bile means there isn't a sin­gle band­width on a de­vice. Even an API can't pre­dict when con­di­tions sud­den­ly get worse be­cause a de­vice moves from Wifi to Edge. In such a volatile en­vi­ron­ment it's back­ward to keep think­ing in mono­lith­ic bitmapped re­sources ar­riv­ing af­ter craft­ing a sin­gle re­quest for it. There's wavelets, pro­gres­sive schemes and vec­tor based im­ages that are much bet­ter at us­ing band­width flex­i­ble and ef­fi­cient­ly be­cause they can stream un­til some­thing de­ter­mines there is enough res­o­lu­tion, and re­sume when more is need­ed. But if you're look­ing for a markup so­lu­tion - be­cause that is what your au­di­ence is crav­ing for - it's just mov­ing the same old pro­to­col into an­oth­er lay­er, ef­fec­tive­ly of­fer­ing the user no ad­van­tage. Just wast­ing time wait­ing to get some­thing into a stan­dard it shouldn't be in in the first place, but ap­par­ent­ly it's to hard to get de­sign­er-slash-de­vel­op­ers to ask serv­er spe­cial­ists to solve their prob­lems prop­er­ly. That's why hey are called HTML mon­keys.

And even if you've gone through such great lengths to pre­vent suck­ing re­dun­dant data over some­one's pre­cious con­nec­tion, only one click seper­ates that user from go­ing to an­oth­er web­site that didn't and makes the ef­fect of your op­ti­mi­sa­tions seem pret­ty use­less. It's like risk­ing your life to re­move a sin­gle mine from a mine­field and then claim you've made an im­prove­ment in safe­ty for the user. But that user isn't go­ing near your sin­gle safe spot as long as all the oth­er mines are still there. Nice tech demo, but in the real world the whole ecosys­tem the user op­er­ates in has to have some min­i­mal lev­el to make it us­able in he first place. And the core of that ecosys­tem is still the brows­er.

Browsers should do a lot more than just im­ple­ment web stan­dards flaw­less­ly. Ini­tia­tives like Opera Mini show users can be giv­en good tools with­out some stan­dards body first have to make a stan­dard for it, or every web­mas­ter come up with his own rein­ven­tion of what should be brows­er fun­cional­i­ty. But if all HTML mon­keys can do is markup and think in markup they will nev­er un­der­stand how to build a brows­er and solve the real prob­lems. They seem to have enough is­sues grasp­ing why browsers don't func­tion as they would ex­pect them to work from their markup view­point any­way.