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.