The document discusses optimizing mobile web apps for performance. It identifies key challenges like limited resources and network latency. Not optimizing can lead to poor user experiences with slow loads and battery drain. The document recommends reducing network usage, showing loading indicators, using HTML5 features, GPU acceleration, and keeping the DOM simple to improve performance and respect the battery. It also provides tips on debugging and testing mobile web apps.
21. ๏ 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
23. WWW 2012 – Session: Mobile Web Performance April 16–20, 2012, Lyon, France
Who Killed My Battery:
Analyzing Mobile Browser Energy Consumption
Narendran Thiagarajan† Gaurav Aggarwal† Angela Nicoara*
naren@cs.stanford.edu agaurav@cs.stanford.edu angela.nicoara@telekom.com
Dan Boneh† Jatinder Pal Singh‡
dabo@cs.stanford.edu 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
ABSTRACT sites are poorly optimized for energy use and rendering them in the
Despite the growing popularity of mobile web browsing, the energy browser takes more power than necessary. Partly this is due to a
consumed by a phone browser while surfing the web is poorly un- weak understanding of the browser’s energy use.
derstood. We present an infrastructure for measuring the precise In this paper we set out to analyze the energy consumption of
energy used by a mobile browser to render web pages. We then the Android browser at popular web sites such as Facebook, Ama-
measure the energy needed to render financial, e-commerce, email, zon, and many others. Our experimental setup includes a multi-
blogging, news and social networking sites. Our tools are suffi- meter hooked up to the phone battery that measures the phone’s
ciently precise to measure the energy needed to render individual energy consumption as the phone loads and renders web pages. We
web elements, such as cascade style sheets (CSS), Javascript, im- patched the default Android browser to help us measure the precise
ages, and plug-in objects. Our results show that for popular sites, energy used from the moment the browser begins navigating to the
downloading and parsing cascade style sheets and Javascript con- desired web site until the page is fully rendered. The patch also lets
sumes a significant fraction of the total energy needed to render the us measure the exact energy needed to render a page excluding the
page. Using the data we collected we make concrete recommen- energy consumed by the radio. Our setup is described in detail in
dations on how to design web pages so as to minimize the energy Section 2. In that section we also describe the energy model for the
needed to render the page. As an example, by modifying scripts on phone’s radio which is similar to models presented in [18, 10].
the Wikipedia mobile site we reduced by 30% the energy needed to Using our experimental setup we measured the energy needed
download and render Wikipedia pages with no change to the user to render popular web sites as well as the energy needed to render
experience. We conclude by estimating the point at which offload- individual web elements such as images, Javascript, and Cascade
ing browser computations to a remote proxy can save energy on the Style Sheets (CSS). We find that complex Javascript and CSS can
phone. be as expensive to render as images. Moreover, dynamic Javascript
Thursday, May 3, 12 requests (in the form of ) can greatly increase
24. Where to start?
Perceived Lag / Power Drain
Optimizations
Thursday, May 3, 12
25. Crunch Points
Loading User Interaction
Network Parsing Execution Rendering Animation Events
Thursday, May 3, 12
26. Tip
Don’t take the network for granted
Thursday, May 3, 12
27. 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
28. How do you
solve a
problem like
the network?
Do everything Steve
Souders tells you to.
Thursday, May 3, 12
29. • 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
30. 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
31. Original PNG JPEG 3bit PNG Mask
33Kb 19Kb 4.7Kb
--- 23.7Kb ~ 29% saving ---
Thursday, May 3, 12
32. Tip
If you really must make the user wait,
show something.
Thursday, May 3, 12
35. Tip
Use HTML5 and other goodies
Thursday, May 3, 12
36. HTML5
• LocalStorage
• AppCache
• Network / Connection API
• Battery API
• Things we don’t need libraries for:
• JSON, QuerySelector, ClassLists
Thursday, May 3, 12
38. Tip
Don't animate anything that you can't reliably
offload to the GPU
Thursday, May 3, 12
39. 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
40. 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
41. Tip
Keep the DOM simple and use event
listeners carefully
Thursday, May 3, 12
43. Build
process
• Build process
• Testing and
debugging
http://floridakeysgirl.com/wp-content/uploads/2010/10/IMG_1147-e1288555102991.jpg
Thursday, May 3, 12
44. Debugging and Testing
• Desktop Webkit
• Simulator / Emulators
• weinre - WEb INspector REmote
• Charles proxy
• Mobile Perf Bookmarklet (YSlow, DOM
Monster)
• PhantomJS, Selenium
• Real devices, with real OSs
Thursday, May 3, 12
45. 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