That's Web? Extreme Optimization for the

Mobile Web

Glan Thomas - Disney InteractiveHTML5 Developer Conference 2012

San Francisco, CA

About me... and why I am interested in this stuff

What is a Mobile Web App?

Browser based

Webview

What’s it like going from the desktop to

mobile web?

Why am interested in this

© Universal Pictures

What are we trying to optimize?

Guest Experience

http://www.flickr.com/photos/stuckincustoms/518435043/

The 5 Great Mobile Development Challenges

➊ Limited CPU and memory resources

➋ Variety of Display Densities

➌ High Network Latency

http://www.qsl.net/ylradio/archives/YLstor/images/radioroom.jpg

➍ MatchingUsers’ Expectations

© DreamWorks Pictures / 20th Century Fox

http://www.flickr.com/photos/youraccount/3939769126/

➎ Harder to Debug

➎ Dealing with your VP’s

pessimism

© 2010 Columbia TriStar

What if we don’t do anything?

✘ Long load times

✘ Partial content appearing

✘ Unresponsive UI

✘ Jittery animations

But It gets worse...

• Unnecessary data usage

• Decreased battery life

http://www.flickr.com/photos/flydime/4670141424/

“Q, your app sucks.

I used it for 30 minutes and it

drained my battery so low

that I missed my appointment with

Dr Crusher!”

Prime Directive

© CBS Paramount Television / Paramount Pictures

๏ MANY + LARGE HTTP REQUESTS = MORE DATA = MORE POWER USAGE= HIGH BATTERY DRAIN

๏ UNNECESSARY ANIMATIONS= HIGH USE OF CPU AND MEMORY = MORE POWER USAGE = HIGH BATTERY DRAIN

PRIME DIRECTIVE"Be green and respect the

battery"

© CBS Paramount Television / Paramount Pictures

Who Killed My Battery:

Analyzing Mobile Browser Energy Consumption

Narendran Thiagarajan

†

naren@cs.stanford.edu

Gaurav Aggarwal

†

agaurav@cs.stanford.edu

Angela Nicoara

*

angela.nicoara@telekom.com

Dan Boneh

†

dabo@cs.stanford.edu

Jatinder Pal Singh

‡

jatinder@stanford.edu

†Department of Computer Science, Stanford University, CA

*Deutsche Telekom R&D Laboratories USA, Los Altos, CA

‡Department of Electrical Engineering, Stanford University, CA

ABSTRACTDespite the growing popularity of mobile web browsing, the energyconsumed by a phone browser while surfing the web is poorly un-derstood. We present an infrastructure for measuring the preciseenergy used by a mobile browser to render web pages. We thenmeasure the energy needed to render financial, e-commerce, email,blogging, news and social networking sites. Our tools are suffi-ciently precise to measure the energy needed to render individualweb elements, such as cascade style sheets (CSS), Javascript, im-ages, and plug-in objects. Our results show that for popular sites,downloading and parsing cascade style sheets and Javascript con-sumes a significant fraction of the total energy needed to render thepage. Using the data we collected we make concrete recommen-dations on how to design web pages so as to minimize the energyneeded to render the page. As an example, by modifying scripts onthe Wikipedia mobile site we reduced by 30% the energy needed todownload and render Wikipedia pages with no change to the userexperience. We conclude by estimating the point at which offload-ing browser computations to a remote proxy can save energy on thephone.

Categories and Subject DescriptorsD.2 [Software]: Software Engineering; D.2.11 [Software Engi-neering]: Software Architectures; D.2.8 [Software Engineering]:Metrics—Performance Measures

General TermsDesign, Measurement, Performance

KeywordsMobile browser, Energy consumption, Offloading computations,Android

1. INTRODUCTIONRecent statistics from NetMarketShare show that about 3% of all

worldwide web browsing is done on mobile browsers [5]. Manypopular sites responded by providing a mobile version of their siteoptimized for a small screen. However, we show that many mobile

Copyright is held by the International World Wide Web Conference Com-mittee (IW3C2). Distribution of these papers is limited to classroom use,and personal use by others.WWW 2012, April 16–20, 2012, Lyon, France.ACM 978-1-4503-1229-5/12/04.

sites are poorly optimized for energy use and rendering them in thebrowser takes more power than necessary. Partly this is due to aweak understanding of the browser’s energy use.

In this paper we set out to analyze the energy consumption ofthe Android browser at popular web sites such as Facebook, Ama-zon, and many others. Our experimental setup includes a multi-meter hooked up to the phone battery that measures the phone’senergy consumption as the phone loads and renders web pages. Wepatched the default Android browser to help us measure the preciseenergy used from the moment the browser begins navigating to thedesired web site until the page is fully rendered. The patch also letsus measure the exact energy needed to render a page excluding theenergy consumed by the radio. Our setup is described in detail inSection 2. In that section we also describe the energy model for thephone’s radio which is similar to models presented in [18, 10].

Using our experimental setup we measured the energy neededto render popular web sites as well as the energy needed to renderindividual web elements such as images, Javascript, and CascadeStyle Sheets (CSS). We find that complex Javascript and CSS canbe as expensive to render as images. Moreover, dynamic Javascriptrequests (in the form of ) can greatly increasethe cost of rendering the page since it prevents the page contentsfrom being cached. Finally, we show that on the Android browser,rendering JPEG images is considerably cheaper than other formatssuch as GIF and PNG for comparable size images. For example,when we translate all images on the Facebook web site to JPEG weobtain considerable energy savings.

Using our energy measurements we suggest guidelines for build-ing energy-efficient web pages, namely pages that reduce energyuse on the client. For example, by applying our guidelines to theWikipedia mobile site we reduced its energy consumption from35 Joules to 25 Joules, a saving of 29%. Our modification sim-ply changes how Javascript works on the page, without affectingthe user experience. The measurements in this paper quantify howmuch energy can be saved by following these guidelines.

Beyond optimization, our experiments let us estimate the effec-tiveness of offloading browser computations to a remote server.Section 5 gives quantitative numbers for a modern smartphone, theAndroid ADP2 phone [2]. We discuss related and future work inSections 6 and 7. To promote further research on building “green”energy efficient web sites we plan to release our experimental setupand measurement code for others to use.

WWW 2012 – Session: Mobile Web Performance April 16–20, 2012, Lyon, France

Crunch Points

Loading User Interaction

Network Parsing Rendering EventsAnimationExecution

5 Tipsfor optimization

Tip ⓵Don’t take the network for granted

Network•High latency.

•Bandwidth costs money (for all parties).

•Might not be there.

• It will definitely drain the battery.

http://www.flickr.com/photos/robert-dolan/3864148280/

How do you solve a problem like the network?

Do everything Steve Souders tells you to.

• Enable Gzip.

• Reduce number of requests.

• Reduce size of responses.

• Expires Headers / Etags

• Use a CDN.

• Deliver device specific content.

• Don’t use the network unless we absolutely positively need to.

Images

• Optimization tools (ImageOptim, ImageAlpha).

• Sprites to reduce requests.

• Device specific images.

• Base64 inline (pros & cons).

• CSS and Unicode Glyphs to replace images.

• CSS image masks for alpha.

Original PNG 33Kb

JPEG19Kb

3bit PNG Mask4.7Kb

--- 23.7Kb ~ 29% saving ---

Tip ⓶If you really must make the user wait,

show something.

Ideal App Usage Cycle• Load App (HTML & CSS)

• Render

• Load Source (JS)

• Parse

• Execute

• Parallel Operations

• User Events

• Deferred Loads (data and images)

Tip ⓷Use HTML5 and other goodies

HTML5

• LocalStorage

• AppCache

• Network / Connection API

• Battery API

• Web workers and shared web workers

• Things we don’t need libraries for:

• JSON, QuerySelector, ClassLists

JavaScript Libraries

• Modular

• Lightweight

• Maintained

• Understandable

Tip ⓸Don't animate anything that you can't reliably

offload to the GPU

The GPU

• translate3d, scale3d, rotate3d

• Beware of the 1024px texture size limit

• Interaction between the CPU and GPU

• Don’t load too much on to it (~10Mb total storage)

Rendering and Updates

• Avoid reflows

• Carefully use opacity/transparency fades.

• requestAnimationFrame

Tip ⓹Keep the DOM simple and use event

listeners carefully

Putting things together

Build process

• Build process

• Testing and debugging

http://floridakeysgirl.com/wp-content/uploads/2010/10/IMG_1147-e1288555102991.jpg

• Desktop Webkit

• Simulator / Emulators

• weinre - WEb INspector REmote

• Charles proxy

• Mobile Perf Bookmarklet (YSlow, DOM Monster)

• PhantomJS, Selenium

• Real devices, with real OSs

Debugging and Testing

Recap

• Prime Directive: Respect the battery.

• #1 Don’t rely too much on the network.

• #2 Show something while loading.

• #3 Use HTML5 extensions.

• #4 Use hardware acceleration.

• #5 Keep the DOM simple. Use event listeners carefully and appropriately.

Thanks for all the fish

@glan