Building Highly Optimized Mobile Web Apps Glan Thomas Future Insights Live 2012 Thursday, May 3, 12
Why am interested in this
© Universal PicturesThursday, May 3, 12
➌ High Network Latency
http://www.qsl.net/ylradio/archives/YLstor/images/radioroom.jpgThursday, May 3, 12
http://www.flickr.com/photos/youraccount/3939769126/
➍ Harder to Debug
Thursday, May 3, 12
➎ MatchingUsers’ Expectations
© DreamWorks Pictures / 20th Century FoxThursday, May 3, 12
What if we don’t do anything?
✘ Long load times
✘ Partial content appearing
✘ Unresponsive UI
✘ Jittery animations
Thursday, May 3, 12
But It gets worse...
• Unnecessary data usage
• Decreased battery life
http://www.flickr.com/photos/flydime/4670141424/Thursday, May 3, 12
“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 PicturesThursday, May 3, 12
๏ 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
Thursday, May 3, 12
PRIME DIRECTIVE"Be green and respect the
battery"
© CBS Paramount Television / Paramount PicturesThursday, May 3, 12
Who Killed My Battery:
Analyzing Mobile Browser Energy Consumption
Narendran Thiagarajan
†
Gaurav Aggarwal
†
Angela Nicoara
*
Dan Boneh
†
Jatinder Pal Singh
‡
†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
Thursday, May 3, 12
Crunch Points
Loading User Interaction
Network Parsing Rendering EventsAnimationExecution
Thursday, May 3, 12
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/Thursday, May 3, 12
How do you solve a problem like the network?
Do everything Steve Souders tells you to.
Thursday, May 3, 12
• 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.
Thursday, May 3, 12
Images
• Use sprites to reduce requests.
• Use optimization tools (ImageOptim, ImageAlpha).
• Device specific images.
• Base64 inline (pros & cons).
• Use CSS masks for alpha.
• JPEGs use less power.
Thursday, May 3, 12
Ideal App Usage Cycle• Load App (HTML & CSS)
• Render
• Load Source (JS)
• Parse
• Execute
• Parallel Operations
• User Events
• Deferred Loads (data and images)
Thursday, May 3, 12
HTML5
• LocalStorage
• AppCache
• Network / Connection API
• Battery API
• Things we don’t need libraries for:
• JSON, QuerySelector, ClassLists
Thursday, May 3, 12
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)
Thursday, May 3, 12
Keeping things on the GPU
• Reduce repaints and reflows
• Avoid box shadows (or use them carefully)
• Avoid opacity/transparency fades.
• Avoid garbage collection during animations
Thursday, May 3, 12
Build process
• Build process
• Testing and debugging
http://floridakeysgirl.com/wp-content/uploads/2010/10/IMG_1147-e1288555102991.jpgThursday, May 3, 12
• 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
Thursday, May 3, 12
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.
Thursday, May 3, 12
Thanks for all the fish
Glan Thomas @glan
Future Insights Live 2012
Las Vegas, NV
Thursday, May 3, 12
Useful Links• Steve Soudershttp://stevesouders.com
• Estelle Weyl@estellevw
• Joe Hewitthttp://joehewitt.com/2011/10/05/fast-animation-with-ios-webkit
• Jake Archibald@jaffathecake
• Thomas Fuchshttp://mir.aculo.us/
• Who Killed My Batteryhttp://www2012.wwwconference.org/proceedings/proceedings/p41.pdf
Thursday, May 3, 12