Mobile Application Performance Tips

0368b95a18e594981083b2eb9b177b2d?s=47 volkan
October 03, 2013

Mobile Application Performance Tips

There are several reason for why most of the mobile apps are not so great in terms of performance.

In this talk, we will be analyzing all those factors
one by one, and try to look at various techniques and
strategies that we can use to mitigate them.

By the end of this talk, the audience will have an solid idea of how to
create fast, intuitive and highly efficient mobile JavaScript applications.

0368b95a18e594981083b2eb9b177b2d?s=128

volkan

October 03, 2013
Tweet

Transcript

  1. Volkan Özçelik 
 me@volkan.io 10/05/2013 #hack4Good hack4good.io Mobile Application 

    Performance  Tips
  2. About Me •Mobile Engineer @ JiveSoftware.com •JavaScript Hacker @ SocialWire.com

    •VP of Technology @ GROU.PS •Project Director @ LiveGO.com (gone to deadpool) •CTO @ cember.net (acquired by Xing)
  3. Other Places You Can Find Me •geekli.st/volkan •github.com/v0lkan •twitter.com/linkibol •linkedin.com/in/volkanozcelik

    •volkan.io
  4. Psst…  I Have a Book o2js.com/interview-questions

  5. Today’s Talk •Why Mobile First? & WhyJavaScript? •Mobile Limitations &

    Challenges •Need For Speed •Network, Render, Cache, React, Execute •Be Frugal •When You Can’t Make it; Fake It •It All Depends •Questions
  6. Why Mobile First? If your stuff, if your content, 


    if your information, if your products, 
 if your services are not available on mobile, they don’t exist for these people. ! Karen McGrane
  7. Why Mobile First? https://blog.compete.com/2010/03/12/smartphone-owners-a-ready-and-willing-audience/ % Daily Mobile Usage (of >2

    hours) 0 6.5 13 19.5 26 At Home At Work While Watching TV While Waiting in Line During Commute
  8. Why JavaScript? Any application that can be written in JavaScript

    will be written in JavaScript. ! Jeff Attwood
  9. Mobile Limitations &  Challenges

  10. Mobile Constraints •Network •State of Radio •Type of Network •Memory

    •Processing Power •Battery
  11. What Kills Your Battery •Network Requests (#1) •JavaScript (#2) •Layered

    Architecture •Extensive OO Programming •Images (#3) •DOM Size (#4)
  12. Desktop Mobile ! http://highscalability.com/blog/2013/9/18/if-youre-programming-a-cell-phone-like-a-server-youre-doing.html

  13. As Fast As Native? Hardware Core OS Services Media Cocoa

    Touch Webkit WebCore JavaScript Runtime
  14. Need4Speed ! ! image credits: http://gamefanmag.com

  15. Need4Speed •Network •Render •Cache •React •Execute

  16. Network Faster

  17. Network is Expensive

  18. Network is Expensive •Use Smart Caching Techniques •Decouple UX From

    Network Activities •Reduce # of HTTP Requests http://www.lukew.com/ff/entry.asp?1797
  19. Decouple UX From Network •Decouple Feedback •Batch Your Requests •Abstract

    Your Server Communication
  20. Decouple UX From Network

  21. Reduce HTTP Requests •Keep Assets on the Device if You

    Can •Inline Critical CSS and JavaScript •Combine Asset •CSS Sprites •Defer Fetching Non-Critical Resources •Reduce Images Used
  22. Latency is Your Nemesis •It’s not the Bandwidth; it’s Latency

    •Latency Kills •Network Requests Are Expensive •More than You Think •Performance is a design feature, treat it that way!
  23. Latency is Your Nemesis •Latency Is Highly Variable •Have an

    “Offline Mode” •Have an Intelligent Retry Strategy •Do Not Retry While Offline •Retry request at increasing intervals; Give up if it all fails.
  24. On Demand Loading •Remember Network Latency •Consider Prefetching Assets •Consider

    Using LocalStorage as a Cache •Know Your Requirements
  25. It’s Complicated •Things Will Change A Lot •HTTP 2.0 •SPDY

    •Perception Is as Important as Reality
  26. Render Faster

  27. Best Practices Still Hold •YSlow •http://developer.yahoo.com/ performance/rules.html •Google PageSpeed •https://developers.google.com/

    speed/pagespeed/
  28. Render Faster •Avoid Shadows and Gradients •Avoid Excessive Animations •Always

    Use CSS To Animate •Use a Simple Logicless Template •Do Not Nest Templates •Do Not Nest View Objects
  29. Avoid Nesting Views

  30. Avoid Nesting Views

  31. Jank Busting •Avoid Jankiness [1] •You have 16ms •Use requestAnimationFrame

    •Have a consistent frame rate •Respond to Everything <100ms •Learn How Browsers Optimize Things •There’s Always a Tradeoff [1] http://jankfree.org/
  32. Go Flat ! •Remove shadows, border radius, gradients… •When more

    than one is combined, it’s lethal! •Things will get worse as your DOM size increases.
  33. 60 FPS Not Only For Games •Scrolling •Orientation Change •Changing/Refreshing

    Views •User Gestures •Swiping •Zooming/Oanning
  34. GPU Acceleration •transform: translateZ(0); •Use Only When Necessary •Always Test

  35. Invisible Elements •position:relative;left:-9999px; •will be painted!

  36. Minimize Reflows •Page Load •Orientation Change •Style Info Request [1]

    •Altering CSS Box Model •Display Changes [1] http://mir.aculo.us/2010/08/17/when-does-javascript-trigger-reflows-and-rendering/
  37. Scrolling •Is a harder problem than you think •Infinite Scroll

    === Infinite Memory •Remove items that are outside the viewport •Try to use fixed-height items •Cache DOM attributes •A tool might be useful [1] [1] http://airbnb.github.io/infinity/
  38. Cache  Faster

  39. Caching to The Rescue •The answer to the meaning of

    life, the universe, and everything is … •Caching!
  40. Use Cache Wisely •HTML5 Application Cache Sucks •Use LocalStorage as

    Much as You Can •IndexedDB/WebSQL are Slower than LocalStorage
  41. Use Cache Wisely •LocalStorage is Limited (5MB) •It’s not as

    much as it seems •You can store part of the data •Retrieve the rest from the server •You can compress the data [1] •With some decompression overhead [1] http://pieroxy.net/blog/pages/lz-string/index.html
  42. Use Cache Wisely •Have a Single Cache Point •LocalStorage is

    Faster •Cap Size of Each Cache Entry •Use a LRU Algorithm [1] •Cache TTL •Cache Eviction •JSON.stringify(localStorage).length [1] https://npmjs.org/package/lru-cache
  43. React  Faster

  44. Responsiveness FTW •User Feedback is Beyond Everything •Never Block UI

    •During a Gesture, UI Should Move •Smooth Transitions (16ms / frame) •Smooth Actions (<100ms)
  45. Responsiveness FTW

  46. Event Handling •Use Event Delegation •300ms Touch Delay •Use Fast

    Click •Prioritize UI Responsiveness
  47. Execute Faster

  48. Frameworks? Think Thrice

  49. Frameworks? Think Thrice! •Frameworks are Expensive •Have Economies of Scale

    •Will Always Be Slower •Frameworks Increase Your Dependency •Frameworks Need Maintenance •Patches •Upgrading •I am NOT saying don’t use them
  50. Frameworks? Think Thrice! A Typical Setup

  51. Frameworks? Think Thrice! With One Modification…

  52. Frameworks? Think Thrice! Results: 0 1250 2500 3750 5000 4397

    4314 4061 445 jQuery jQuery + jQ Mobile jQ + jQM + Underscore jQ + jQM + US + Backbone # of function calls: •This is just to “warm up”. •Nothing is rendered on the page yet.
  53. Frameworks? Think Thrice! jQuery +
 jQuery Mobile + 
 Underscore

    + 
 Backbone +
 Your Business Logic 
 (BLL + DAL + Cache)+
 Helper Plugins =
 
 
 

  54. Frameworks? Think Thrice! $(‘#baz’) document.getElementById $el.attr(‘foo’) el.getAttribute $(‘.foo .bar >

    baz’) document.querySelectorAll $(‘.foo’).click(fn) document.addEventListener
  55. Memory Leaks •It’s Not Magic •Extremely Important For Mobile •Always

    Be Testing For Leaks •Manage Memory Wisely •Object Pools [1] [1] http://buildnewgames.com/garbage-collector-friendly-code/
  56. Memory Leaks

  57. Reduce DOM Access •DOM is a Sync API •JavaScript is

    Single-Threaded •Think UI Thread as if it’s a Node.JS Event Loop •Yield as Fast as You Can
  58. Web Workers •Are Supported on Most Mobile Platforms •Yield Heavy

    Computations to Them
  59. Be Frugal

  60. Be Frugal: Reduce JavaScript •Do As Little As Possible [1]

    •Page Visibility API •Don’t Drain Your Users’ Battery •“Inception” Rule •Remove Unused JavaScript [2] •Reduce JSON Payload [2] http://gotwarlost.github.io/istanbul/ [1] http://alistapart.com/column/do-as-little-as-possible
  61. Be Frugal: Reduce DOM •Reduce DOM Node Size and Depth

    •Reduce the Number of Offline Nodes •Don’t Cache Nodes, Cache Data •Has an Additional Parsing/ Rendering Cost
  62. Be Frugal: Reduce Network •Batch Your Requests •Buffer/Queue Your Requests

    •Combine them and send in batches. •Will be useful for “offline mode”
  63. Be Frugal: Reduce Network •The fastest request is no request

    at all. •With fewer network requests: •Your app will be faster •Your battery will live longer
  64. Be Frugal: Know Your Budget •Set a Performance Budget •Make

    this a Design Constraint •If A New Feature Fail Your Budget: [1] •Either Optimize Existing Features; •Or Remove Existing Features; •Or Don’t Add the New Feature. [1] http://fsm.bdconf.com/podcast/web-performance
  65. Cannot Make It? Fake It

  66. Cannot Make It? Fake It •Providing any kind of progress

    will make app feel faster. •Overestimate remaining time. •Feedback that starts earlier feels to finish sooner. •When in Doubt, KISS
  67. Cannot Make It? Fake It •What Users Hate Most: •Lack

    of Immediate Feedback (#1) •Janky Scrolling (#2) •Tap Delay (#3)
  68. It All Depends

  69. Know Thy App •Each app has different performance needs •Each

    app has different bottlenecks •Each app has a different audience •Each app is a different beast •Always measure, never assume!
  70. Know Thy App •Don’t Optimize W/O Measurement •Be Frugal •Don’t

    Upscale, Always Downscale •Each Added Feature has a Cost •Have a Performance Budget
  71. Know Thy App •First Profile on Desktop Browser •to Have

    an Initial Idea •Then Test on a Real Device •Do Not Trust Simulator/Emulator •Test on a Mobile Network
  72. Always Test Your Assumptions ops/sec 0 3500000 7000000 10500000 14000000

    114187 12777996 getElementsByClassName querySelectorAll http://jsperf.com/getelementbyid-vs-getelementsbyclassname/21
  73. Entropy Always Increases •Coding Things Right is Not Enough •Your

    App’s Performance Won’t Stay the Same •Your App’s Performance Won’t Improve •Unless You Regularly Pay Attention •There is Always a Tradeoff
  74. People to Follow •@linkibol (me :D ) •@standardista (Estelle Weyl)

    •@souders (Steve Souders) •@slicknet (Nicholas Zakas) •@codepo8 (Christian Heilmann) •@firt (Maximiliano Firtman) •@ariyahidayat (Aria Hidayat) •@stubbornella (Nicole Sullivan) * Names don’t have any specific order. * Not a comprehensive list.
  75. Thank You Questions?