Recently, technology reporter Jacob Aron wrote a blog post on newscientist.com that talks about how bloated website code drains your smartphone’s battery.

He mentions how Stanford computer scientist Narendran Thiagarajan and colleagues used an Android phone hooked up to a multimeter to measure the energy used in downloading and rendering popular websites. Using their experimental setup they measured the energy needed to render popular web sites as well as the energy needed to render individual web elements such as images, Javascript, and Cascading Style Sheets (CSS). They claim that complex Javascript and CSS can be as expensive to render as images. Moreover, dynamic Javascript requests (in the form ofXMLHttpRequest) can greatly increase the cost of rendering the page, since it prevents the page contents from being cached. Finally, they show that on the Android browser, rendering JPEG images is considerably cheaper than other formats, such as GIF and PNG for comparably sized images.

One example that is cited is that simply loading the mobile version of Wikipedia over a3G connection consumed just over 1 per cent of the phone’s battery, while browsing apple.com, which does not have a mobile version, used 1.4 per cent.

Yet, in the summary of the paper they find that the results from this study are not meaningful except for the initial loading of just a single page resource. It would be interesting to extend these results in a meaningful way, and study the energy signature of an entire browsing session at a site such as Wikipedia, where a user typically moves from page to page. So, during that session, downloaded web elements such as Javascript, CSS and images would mostly be cached locally. Therefore, we really can’t estimate the energy cost of a total session by simply summing the energy usage of pages visited during that session. Measuring an entire typical session may help optimize the power signature of the entire site. Custom CSS that is applicable to every page of a site would easily outweigh the cost of the apparently excessive CSS download for the render of just the first page.

So, one of the ways that we are looking to improve our mobile browser energy consumption is by implementing the MediaWiki ResourceLoader in order to improve the load times for JavaScript and CSS. ResourceLoader is the delivery system in MediaWiki for the optimized loading and managing of modules. Its purpose is to improve MediaWiki’s front-end performance and the experience by making use of strong caching while still allowing near-instant deployment of new code that all clients start using within 5 minutes. Modules are built of JavaScript, CSS and interface messages; it was first released in MediaWiki 1.17.

On Wikimedia wikis, every page view includes hundreds of kilobytes of JavaScript. In many cases, some or all of this code goes unused due to browser support or because users do not make use of the features on the page. In these cases, bandwidth and loading time spent on downloading, parsing and executing JavaScript code are wasted. This is especially true when users visit MediaWiki sites using older browsers, like Internet Explorer 6, where almost all features are unsupported, and parsing and executing JavaScript is extremely slow.

ResourceLoader solves this problem by loading resources on demand and only for browsers that can run them. Although there is too much to summarize in a simple list, the major improvements for client-side performance are gained by:

• Minifying and concatenating

• → which reduces the code’s size and parsing/download time

• JavaScript files, CSS files and interface messages are loaded in a single special formatted “ResourceLoader Implement” server response.

• Batch loading

• → which reduces the number of requests made

• The server response for module loading supports loading multiple modules so that a single response contains multiple ResourceLoader Implements, which in itself contain the minified and concatenated result of multiple javascript/css files.

• Data URIs embedding

• → which further reduces the number of requests, response time and bandwidth

• Optionally images referenced in stylesheets can be embedded as data URIs. Together with the gzippping of the server response, those embedded images, together, function as a “super sprite”.