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.

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?