Too Hot To Handle - Optimizing for Low Powered Devices

Bf8ea4b5c4f3d94db2bb16dff9ca626b?s=47 Simon Hearne
September 21, 2016

Too Hot To Handle - Optimizing for Low Powered Devices

We know what web performance is—getting pages to render fast for as many customers as possible. Traditionally, the focus has been on the network, improving the time to deliver critical content, but the combination of modern web applications, better network connectivity, and HTTP/2 is reducing the impact of the network on site speed. Our next great challenge is how well our applications perform on our customer’s CPU. As our dependency on the CPU has inevitably increased, our devices have gotten smaller, and processors have struggled to keep up with Moore’s Law. Meanwhile, our ability to profile and analyze the CPU footprint of our web applications has barely improved beyond the timeline in Chrome’s Developer Tools.

Simon Hearne explains why the CPU will soon be the biggest challenge for web performance (if it isn’t already), explores the many tasks that now rely on the CPU and the impact that these have on user experience, and demonstrates how to profile CPU usage to find issues and limit their impact as well as how to manage CPU load at scale to ensure that every customer gets a good experience, regardless of gigahertz.

JavaScript frameworks have been proliferating in web development for a decade. From jQuery to ReactJS, the goal has been simple: to make it easier to develop reliable web applications. However, increasing developer convenience and decreasing time to market may have come at a cost—JavaScript applications are often CPU intensive, especially when a visitor first loads the site. The impact of this performance challenge has remained relatively unexplored to date, with traditional site speed metrics failing to capture crucial information around application performance.

Alongside the growth in JavaScript frameworks, the use of third parties to deliver business value has increased dramatically. These scripts consume CPU cycles whether they provide reviews, recommendations, analytics, or feature detection. The impact of these scripts can be huge, with many seconds of valuable render time lost to overworked processors.

Potentially compounding the additional load on our customers’ processors is our move to richer web technologies. We create intricate images and animations in CSS3 and SVG that were previously only possible with video. Web sockets, WebRTC, and service workers allow us to do much more with real-time communication. High-resolution images look great on large screens but can weigh heavily on a CPU when they need to be scaled. All of these advancements create increasing demand on web browsers at a moment when we have an ever-decreasing slice of our customer’s CPU thanks to multitasking across tabs and applications.

Bf8ea4b5c4f3d94db2bb16dff9ca626b?s=128

Simon Hearne

September 21, 2016
Tweet

Transcript

  1. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 1 TOO HOT TO HANDLE OPTIMIZING FOR LOW POWERED DEVICES
  2. 2 Simon Hearne @SimonHearne Senior Performance Consultant NCC Group slides:

    hearne.me/2hot slides
  3. 3 Things I Make

  4. 4 1. Device Diversity 2. Developer Convenience 3. Unpredictable Hardware

    4. JavaScript Performance is Critical to User Experience 5. We Don’t Have the Tools 6. So What Do We Do?
  5. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 5
  6. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 6
  7. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 7 Performance was ‘the same’
  8. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 8 High conversion rate expectations… -40%
  9. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 9
  10. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 10 User feedback was poor “Old-fashioned” “clunky” “hard to use” “slow” “tired” “frustrating”
  11. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 11
  12. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 12 0.00% 0.50% 1.00% 1.50% 2.00% 2.50% 3.00% 0 2 4 6 8 10 12 14 16 18 20 Page Impressions Page Load Time (s) Desktop Smartphone Smartphone experience slower than desktop
  13. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 13 “ ” people on mobile expect a slower experience A Customer
  14. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 14 Your users’ expectations are set by their most recent interactions.
  15. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 15 Your users’ expectations are set by their most recent interactions. On mobile, that means you’re competing with the OS and native applications
  16. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 16 Mobile users are not patient.
  17. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 17 53% The need for mobile speed. DoubleClick, September 2016. of visits are abandoned if a mobile page takes over three seconds Mobile users are not patient.
  18. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 18 0.00% 0.50% 1.00% 1.50% 2.00% 2.50% 3.00% 0 2 4 6 8 10 12 14 16 18 20 Page Impressions Page Load Time (s) Android iOS Android experience slower than iPhone
  19. 19 Device Diversity Increasing device diversity has led to a

    ‘great on some, okay on all’ attitude
  20. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 20
  21. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 21
  22. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 23 “ ” Responsive web design is a fluid grid, flexible images and media queries Ethan Marcotte (2010)
  23. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 24 RESPONSIVE WEB DESIGN WAS CREATED WHEN MOBILE TRAFFIC WAS < 3% http://www.statista.com/statistics/241462/global-mobile-phone-website-traffic-share/
  24. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 25 RESPONSIVE WEB DESIGN WAS CREATED WHEN MOBILE TRAFFIC WAS < 3% MOBILE TRAFFIC IS NOW >40% http://www.statista.com/statistics/241462/global-mobile-phone-website-traffic-share/
  25. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 27 US Android market share is 25% greater than iPhone 2016 U.S. Cross-Platform Future in Focus – ConScore Inc. 53% 43%
  26. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 28 (p.s. smartphone ⊆ mobile)
  27. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 29 Smart TV Smart Watch Raspberry Pi Games Console Wireless Router 2% of Ecommerce Traffic
  28. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 30 COMING SOON TO A FUTURE NEAR YOU… IN-CAR WEB BROWSERS
  29. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 31 COMING SOON TO A FUTURE NEAR YOU… APPLIANCE WEB BROWSERS
  30. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 32 COMING SOON TO A FUTURE NEAR YOU… WEARABLE WEB BROWSERS
  31. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 33 Responsive (generally) means a desktop site on non-desktop devices
  32. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 36 RULE 1 Responsive Web Design Is Not Enough
  33. 37 Developer Convenience We prioritise developer convenience over user experience

  34. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 38 “ ” Responsive web design is a fluid grid, flexible images and media queries Ethan Marcotte (2010)
  35. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 39 i.e. develop one code-base & compromise on most viewports
  36. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 40 the way we consume the web has changed 19% http://www.pewinternet.org/2015/04/01/us-smartphone-use-in-2015/ of adults in the United States are Smartphone-dependent
  37. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 42 Mobile revenue share is increasing 2016 U.S. Cross Platform Future in Focus – ComScore Inc. 16.9% of digital revenue is mobile 3.6% 9.0% 11.3% 11.7% 13.0% 16.9% 2010 2011 2012 2013 2014 2015
  38. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 44 2007 2016 the way we develop for the web has changed
  39. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 46 MOBILE USERS JAVASCRIPT FRAMEWORKS
  40. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 47 15% “Building Pew Research Center’s American Trends Panel,” April 8, 2015 do not have JavaScript enabled devices” “among our 5,400 panellists
  41. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 48 1.1% https://gds.blog.gov.uk/2013/10/21/how-many-people-are-missing-out-on-javascript-enhancement/ of UK traffic does not execute JavaScript
  42. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 50 JavaScript frameworks take our code from a safe and controlled environment (server) to the wild west (client).
  43. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 51 RULE 2 Question the Use of JavaScript Frameworks
  44. 52 Unpredictable Hardware We can’t control our users’ devices. Even

    high-end devices can perform poorly.
  45. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 53 “ ” Our customers use iPhones and high-end Android phones, so performance isn’t an issue A Customer
  46. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 54 JetStream JavaScript Benchmark (bigger = better) 48 14 Galaxy S6 Moto G (3rd Ed.)
  47. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 55 JetStream JavaScript Benchmark (bigger = better) 48 37 14 Galaxy S6 Galaxy S6 (Power Saving) Moto G (3rd Ed.)
  48. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 56 JetStream JavaScript Benchmark (bigger = better) 48 37 25 14 Galaxy S6 Galaxy S6 (Power Saving) Galaxy S6 (In the Sun) Moto G (3rd Ed.)
  49. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 57 JetStream JavaScript Benchmark (bigger = better) 63 52 48 37 25 14 iPhone 6 iPhone 5S Galaxy S6 Galaxy S6 (Power Saving) Galaxy S6 (In the Sun) Moto G (3rd Ed.)
  50. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 58 JetStream JavaScript Benchmark (bigger = better) 63 52 48 37 25 21 14 iPhone 6 iPhone 5S Galaxy S6 Galaxy S6 (Power Saving) Galaxy S6 (In the Sun) iPhone 5C Moto G (3rd Ed.)
  51. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 59 JetStream JavaScript Benchmark (bigger = better) 160 63 52 48 37 25 21 14 iPhone 7 iPhone 6 iPhone 5S Galaxy S6 Galaxy S6 (Power Saving) Galaxy S6 (In the Sun) iPhone 5C Moto G (3rd Ed.)
  52. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 61 Increasing Performance Fragmentation
  53. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 62 Should low-income users get a poorer web experience?
  54. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 63 Do you test performance on low-end devices?
  55. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 64 RULE 3 Test on low-end hardware (it’s cheap!)
  56. 65 JavaScript Performance is Critical to User Experience

  57. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 66 Facebook @ Line Speed 2x Faster (at least) https://www.webpagetest.org/video/compare.php?tests=160918_2A_SSH,160918_05_SSF
  58. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 67 Facebook @ Line Speed 2186 322 177 52 5 46 20 9 0 500 1000 1500 2000 2500 Scripting Layout Loading Painting Processing Breakdown (ms) mbasic.facebook.com m.facebook.com https://www.webpagetest.org/breakdownTimeline.php?test=160918_2A_SSH , https://www.webpagetest.org/breakdownTimeline.php?test=160918_05_SSF
  59. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 68 700ms https://timkadlec.com/2014/09/js-parse-and-execution-time/ on low-powered devices Parsing & executing jQuery can take
  60. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 69 • QuantCast top 10,000 websites • WebPageTest Private • AWS North California • Chrome mobile emulation • Cable speed • 8,289 valid page tests • 12.4% have a single-page application framework (hearne.me/spajs) Here comes some data…
  61. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 70 43% Measured by Speed Index slower than those without mobile sites with SPA frameworks are
  62. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 71 500ms longer to start render mobile sites with SPA frameworks take
  63. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 72 0 2000 4000 6000 8000 10000 12000 14000 none angular react backbone dojo unknown knockout MEDIAN of CPU Time MEDIAN of Speed Index MEDIAN of Visually Complete hearne.me/spadata
  64. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 73 0 2000 4000 6000 8000 10000 12000 14000 none angular react backbone dojo unknown knockout MEDIAN of CPU Time MEDIAN of Speed Index MEDIAN of Visually Complete hearne.me/spadata
  65. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 74 WPT API Chrome Mobile Chrome Desktop
  66. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 75 You can make it faster
  67. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 76 Any JavaScript single-page application framework or template can be pre-rendered
  68. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 77 Angular 2 Universal Pre-Render https://angular.io/features.html
  69. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 78 Angular 2 Universal Pre-Render https://angular.io/features.html
  70. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 80 But It’s Not Just Page Loads…
  71. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 81 But It’s Not Just Page Loads…
  72. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 83 Third-Parties can lock the UI 1,000 ms
  73. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 84 Beware of onBeforeUnload 250ms input latency!
  74. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 85 RULE 4 Measure and Monitor CPU Usage Including page interactions!
  75. 86 We Don’t Have the Tools You can’t manage what

    you don’t measure.
  76. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 87 Developer Machines vs Customer Machines
  77. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 88 Emulation is NOT GOOD ENOUGH but this helps
  78. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 89 https://www.webpagetest.org/video/compare.php?tests=160915_V5_2177,160915_6R_2170
  79. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 90 Mobile Labs are Design-Focused https://codeascraft.com/2013/08/09/mobile-device-lab/
  80. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 91 Chrome & Safari Remote Debugging
  81. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 92 Use Real Data!
  82. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 93 “ ” The Web Performance industry is lacking a good way of measuring real client CPU usage Me, just now
  83. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 94
  84. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 95 RULE 5 Understand the Data & Invest in a Mobile Performance Lab
  85. 96 So… What do we do? the Web is not

    about pixel perfect results for a reduced subset of devices
  86. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 97 Progressive Web Apps to the rescue
  87. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 98 Progressive Web Apps to the rescue
  88. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 99 provide the best user experience possible, given the current conditions
  89. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 100 HTML CSS Images (ATF) JavaScript Additional Content Third-Party Content Core Experience Progressive Enhancement Bloat >94% of transferred bytes (<14kB) http://mobile.httparchive.org/trends.php
  90. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 101 back to m.
  91. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 102 back to m. without the m.
  92. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 103
  93. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 105 https://medium.com/engineering-housing/progressing-mobile-web-fac3efb8b454
  94. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 106 https://speakerdeck.com/steveworkman/adapting-for-the-times?slide=22
  95. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 107 RULE 6 Split Your Codebase When Necessary
  96. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 108 SUMMARY 1. Responsive Web Design is Not Enough 2. Question the Use of JavaScript Frameworks - yes, even jQuery 3. Test on Low-End Hardware – It’s Cheap! 4. Measure and Monitor CPU Usage - Including page interactions! 5. Understand the Data & Invest in a Mobile Lab 6. Split the Codebase When Necessary
  97. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 109 1. Mobile networks – 5G is coming 2. Third-Party Content 3. AMP 4. Image Performance WE HAVEN’T COVERED IT ALL
  98. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 110 Test your mobile site in WebPageTestwith JavaScript disabled ONE THING (using emulation as it doesn’t work on devices)
  99. Thank You @SimonHearne simon@hearne.me webperf.ninja/ Stay in touch!

  100. @SimonHearne • Optimizing for Low Powered Devices • Velocity New

    York 2016 112