Analyzing Mobile Browser Energy Consumption

Recently, technology reporter Jacob Aron wrote a blog post on 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, 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”.

Patrick Reilly, Senior Software Developer, Mobile
  • Copyright notes: “Phone charging” by Eml5526.sp11.team1.adam, in the public domain, from Wikimedia Commons.

Calling mobile testers for round two

Thanks to everyone for participating in our first round of mobile gateway testing.

This time around we’d like you to have our new mobile gateway for your default experience.

Follow this link on your mobile phone to opt in: and send us feedback.

Visually the gateway should look pretty much the same minus a beta logo. All the other changes are under the hood. If you can’t tell the difference between this and the old gateway then we’ve done our job.

Please let us know of any issues on our feedback page and if you don’t want to be in the beta then follow this link to opt out: .

For those coming back; here are some of the issues that you guys reported that we fixed

  • Missing templates – We’re now using live content so this shouldn’t be an issue.
  • Mismatched Japanese & English templates – see above
  • Missing devices – We’ve added a lot more devices through WURFL. If yours is still having issues let us know.
  • Don’t redirect tablets – Fixed!
  • Remove the donate banners – Fixed!
  • … and numerous others

You can learn more about our mobile projects and future work by visitingour Mobile Projects page. If you are a developer and would like to get involved, check out the page detailing our work. And if you just want to say hello or give us some super quick feedback then join us on irc through freenode #wikimedia-mobile

Thanks for making Wikipedia Mobile better for everyone.