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.
The phone in a developer's pocket is not the phone in a user's pocket. Everything in this talk follows from that gap.
About the talkPermalink to this heading
Responsive design solved layout. It did not solve the fact that a mid-range Android handset has a fraction of the CPU budget of the flagship it was designed on, and that CPU, rather than bandwidth, is what most modern pages are actually constrained by.
This talk is about that constraint: how wide real device diversity runs, why the conveniences that make development pleasant make execution expensive, and what to do when a large share of your users are on hardware you have never held.
What's coveredPermalink to this heading
- How wide the gap is. Android held 53% of the US market against the iPhone's 43%, and 19% of US adults were smartphone-dependent — their phone was their only route online.
- What it costs. 53% of mobile visits were abandoned past three seconds (DoubleClick, September 2016). Mobile accounted for 16.9% of digital revenue that year.
- The framework tax. Sites built with SPA frameworks measured 43% slower by Speed Index, and took 500ms longer to start rendering on mobile.
- The users you cannot see. Roughly 15% of a 5,400-person survey were browsing without working JavaScript.
- Six rules. Responsive design is not enough; question the framework; test on low-end hardware; measure CPU, not just network; build a device lab; split the codebase when you must.
- What actually helps. Pre-rendering single-page apps, progressive enhancement around a core experience, and testing with JavaScript disabled in WebPageTest.
Presented at Velocity New York 2016.