Business leaders understand the value of quality and consistent web experiences. Their customers demand it; and, in today’s always-on, digital world, it can make all the difference between keeping a customer and losing one.
A major element to providing great online experiences is having the ability to quickly identify and remediate digital performance issues, such as webpage slowdowns or crashes. Among the most important, but often overlooked, roadblocks to properly identifying performance issues are CPU-related bottlenecks.
What Is a CPU bottleneck?
When a browser loads a page, it does much more than send requests over the network. Much of the complexity that goes into displaying web content involves loading key resources, creating the document object model, rendering content on the screen, executing JavaScript, and loading third-party content.
As the web has evolved, pages have become inherently more complex and JavaScript-heavy. In fact, some sites are actually serving more bytes of compressed JavaScript than images. Addy Osmani, a senior staff software engineer (manager) at Google, recently wrote a blog post, titled “The Cost of JavaScript in 2019,” in which he explored why this is a problem. These are some of Osmani’s key points:
- JavaScript execution times are one part of the equation.
- Many sites use large monolithic bundles, which take longer to parse and evaluate.
- Browsers also need to download your JavaScript bundles in the first place, so ensuring that they are compressed and delivered via a CDN [content delivery network] is a must.
- Lower-end devices are less capable of executing JavaScript as quickly.
Web performance issues can often be categorized based on either CPU or bandwidth bottlenecks. CPU constraints can cause all sorts of bad experiences, from clicking a button on a page that causes nothing to happen, to loading a page to see a continuous white screen, and watching a page jump around as different elements build and load at different times.
With mobile access accounting for almost 53% of all web traffic (based on Akamai’s platform data from June 2019), we are truly living in a mobile-first world right now. Therefore, it’s more important now than ever to optimize for CPU-constrained mobile devices. For example, consider that, when CPU is the limiting factor for loading web content, there is a cascading effect across different device types due to fragmentation. Device capabilities vary, and some lower-end devices will struggle more than higher-end devices.
Identifying a Bottleneck
There are several ways to identify whether a CPU bottleneck is the culprit behind poor web or mobile performance. Here are some of the easiest ways to examine this:
When examining performance via RUM, you are always measuring performance from real end-user devices. Depending on how you are measuring mobile performance, you may either be using real or simulated devices. If you are simulating a mobile device, then you may be masking some of the CPU-related bottlenecks since the measurements will run from a more powerful CPU. However, it is possible to slow down your CPU using tools such as Chrome DevTools. This allows you to simulate low-end hardware and capture a performance profile that includes a summary of execution times as well as a flame chart of what the browser was doing.
For more articles like this one, go to the 2020 Data Sourcebook
If you are looking into specific delays, it makes sense to examine “between” metrics. For example, you can look at First Contentful Paint (https://developers.google.com/web/tools/lighthouse/audits/first-content?ful-paint), which is the time between navigating to a page and the first object from the Document Object Model being painted to screen; onload (www.w3schools.com/jsref/event_onload.asp), which is triggered once the browser is done loading all the objects on the page it discovered in the HTM; and the Time to Interactive metric (https://developers.google.com/web/tools/light?house/audits/time-to-interactive), which is the time when the page is actually ready to use. These are all elements to consider.