5 ways you can speed up First CPU idle
Load is not a single moment in time — it’s an experience that no one metric can fully capture. Shubhie Panicker, Google EngineerAnyone familiar with optimizing their Lighthouse score will appreciate the multi-stage journey that begins whenever a new page is clicked. But, if there is one moment in the loading of a page that seems to demand more attention than others it’s the First CPU Idle. First CPU idle is the time it takes for a page’s main thread to be quiet enough to handle input from the user. Despite the nuances of what defines loading, this is the line most users would define as the point between ‘loading’ and ‘loaded’. That’s why it’s so crucial. As one of the 6 measurements in the Performance section of Google’s Lighthouse score (accounting for 13% of total weighting), cutting the first CPU idle time is key to improving Lighthouse scores, SEO results, and user experiences.
But any publisher looking to optimize their score should adapt their strategy as soon as possible.
First CPU idle will be removed from Lighthouse V6
Due to be released in early 2020, V6 will no longer measure this metric as part of your Lighthouse score.
You can get a complete guide to all the changes that will take place as part of Lighthouse V.6 here. Simply, it’s too similar to Time to Interactive—the time it takes for the page to become fully interactive for user actions—to justify having both metrics. So the good news is that publishers no longer have to worry about both first CPU idle and Time to Interactive. The bad news is that Time to Interactive is now more important than ever.
Meet the new boss, same as the old boss
Time to Interactive is when useful page content is loaded and is interactive to user input. Buttons can be pressed, content swiped, but some elements may still be loading in the background.
As interaction relies on content, TTI requires the First Contentful Paint to load first, in order to interact with it. Interactive is then defined when a 50-millisecond interaction response is available and when all event handlers are registered for most visible page elements.
The Time to Interactive score will have a weighting of 15% in performance scores in Lighthouse V.6. Your TTI will get a ‘grade’ depending on your speed when V.6 is released.
0 – 2.2 seconds is‘excellent2.2 – 5 seconds is ‘fastOver 7 seconds is ‘slow’
Fortunately, these metrics are closely related. You can optimize your First CPU idle time now, and have positive effects on your Time to Interactive results.
How to improve Time to Interactive:
Remove any unused JavaScript
JavaScript execution time affect. Excessive JavaScript libraries and third-party scripts are often the reason behind a slow TTI. To speed this process up, you need to search and destroy any unnecessary Javascript. Libraries often contain code this not being used, you can detect this by analyzing your bundles for code that isn’t being utilized.
Open DevTools, click Network and Disable Cache, and then reload the page.
Within the Coverage tab, clicking on the on a URL reveals that file in the Sources panel with a breakdown of which lines of code executed, with the red showing all code that did not execute.
Bundlers such as Webpack can analyze what makes up each bundle, visualize a treemap of these components, and allow you to see any unused or unnecessary libraries. Remove any unused libraries. Lazyload any libraries not used in the initial page load.
Minify and compress your files
Once you have reduced your JavaScript to the essentials, you can then bring your TTI down through Minification and Data compression. Tools such as Terser can be used to remove the whitespace from your Javascript, creating a smaller but just as functional code file. In addition, optimized asset formats such as WebP can help bring down page weight.
Compressors then use an algorithm to remove redundant data in each file by finding and replacing recurring patterns with smaller variables. Brotli compression currently has the best rates of compression, creating files with 20–26% higher compression ratios, with lossless results.
Cut wait and weight with code-splitting
When a user clicks, you can split your Javascript bundle to only serve the code for the initial interaction. A smaller script means less to be parsed and compiled, meaning a faster page load. The open-source project, Webpack allows you to split code and load them ‘on-demand’ or in parallel with each other and prevent duplicate code from being executed.
Preload and prefetch
When you know the elements that make your browser interactive, you can tell the browser to fetch that resource sooner. The critical request chain is the order that these resources are prioritized and fetched.
Lighthouse classes anything on or after the third level as ‘late-discovered’. A Preload key request audit will help you determine the resources to preload in order to prevent bottlenecks that will slow your page.
Pre-cache assets
To prevent time-consuming repeat visits, service workers can fetch assets directly from the cache rather than the server. With round trips saved, it makes returning visits faster and allows users to access content offline.
RPL pattern
With these steps taken, publishers can then apply the PRPL pattern for the fastest possible time to an interactive page. PRPL is an acronym that stands for:
- Preload only important resources.
- Render the initial route as soon as possible.
- Pre-cache any remaining assets.
- Lazy load other non-critical assets.
The good thing about these optimization techniques is that the concepts don’t need to be optimized together. Everything you do here can have a positive impact on your page speed and Lighthouse score. But, by adopting this approach and using Google’s Lighthouse tool to understand the crucial elements for the first interactive screen, publishers can make major improvements to their load time. The results will be readers that find your pages sticker, lower bounce rates, improvements to SEO, and ultimately, higher traffic.
If you’d like to see how Marfeel’s platform can apply all of these best practices, and more to your mobile site, schedule a demo. One of our team will show you the improvements that platform publishing can have on your performance, instantly. 
Due to be released in early 2020, V6 will no longer measure this metric as part of your Lighthouse score.
You can get a complete guide to all the changes that will take place as part of Lighthouse V.6 here. Simply, it’s too similar to Time to Interactive—the time it takes for the page to become fully interactive for user actions—to justify having both metrics. So the good news is that publishers no longer have to worry about both first CPU idle and Time to Interactive. The bad news is that Time to Interactive is now more important than ever.
Meet the new boss, same as the old boss
Meet the new boss, same as the old boss
Time to Interactive is when useful page content is loaded and is interactive to user input. Buttons can be pressed, content swiped, but some elements may still be loading in the background.
As interaction relies on content, TTI requires the First Contentful Paint to load first, in order to interact with it. Interactive is then defined when a 50-millisecond interaction response is available and when all event handlers are registered for most visible page elements.
The Time to Interactive score will have a weighting of 15% in performance scores in Lighthouse V.6. Your TTI will get a ‘grade’ depending on your speed when V.6 is released.
0 – 2.2 seconds is‘excellent
2.2 – 5 seconds is ‘fast
Over 7 seconds is ‘slow’
Fortunately, these metrics are closely related. You can optimize your First CPU idle time now, and have positive effects on your Time to Interactive results.
Fortunately, these metrics are closely related. You can optimize your First CPU idle time now, and have positive effects on your Time to Interactive results.
How to improve Time to Interactive:
Remove any unused JavaScript
JavaScript execution time affect. Excessive JavaScript libraries and third-party scripts are often the reason behind a slow TTI. To speed this process up, you need to search and destroy any unnecessary Javascript. Libraries often contain code this not being used, you can detect this by analyzing your bundles for code that isn’t being utilized.
Open DevTools, click Network and Disable Cache, and then
reload the page.
Within the Coverage tab, clicking on the on a URL reveals that file in the Sources panel with a breakdown of which lines of code executed, with the red showing all code that did not execute.
Bundlers such as Webpack can analyze what makes up each bundle, visualize a treemap of these components, and allow you to see any unused or unnecessary libraries. Remove any unused libraries. Lazyload any libraries not used in the initial page load.
Minify and compress your files
Once you have reduced your JavaScript to the essentials, you can then bring your TTI down through Minification and Data compression. Tools such as Terser can be used to remove the whitespace from your Javascript, creating a smaller but just as functional code file. In addition, optimized asset formats such as WebP can help bring down page weight.
Compressors then use an algorithm to remove redundant data in each file by finding and replacing recurring patterns with smaller variables. Brotli compression currently has the best rates of compression, creating files with 20–26% higher compression ratios, with lossless results.
Cut wait and weight with code-splitting
When a user clicks, you can split your Javascript bundle to only serve the code for the initial interaction. A smaller script means less to be parsed and compiled, meaning a faster page load. The open-source project, Webpack allows you to split code and load them ‘on-demand’ or in parallel with each other and prevent duplicate code from being executed.
Preload and prefetch
When you know the elements that make your browser interactive, you can tell the browser to fetch that resource sooner. The critical request chain is the order that these resources are prioritized and fetched.
Lighthouse classes anything on or after the third level as ‘late-discovered’. A Preload key request audit will help you determine the resources to preload in order to prevent bottlenecks that will slow your page.
Pre-cache assets
To prevent time-consuming repeat visits, service workers can fetch assets directly from the cache rather than the server. With round trips saved, it makes returning visits faster and allows users to access content offline.
RPL pattern
With these steps taken, publishers can then apply the PRPL pattern for the fastest possible time to an interactive page. PRPL is an acronym that stands for:
- Preload only important resources.
- Render the initial route as soon as possible.
- Pre-cache any remaining assets.
- Lazy load other non-critical assets.
The good thing about these optimization techniques is that the concepts don’t need to be optimized together. Everything you do here can have a positive impact on your page speed and Lighthouse score. But, by adopting this approach and using Google’s Lighthouse tool to understand the crucial elements for the first interactive screen, publishers can make major improvements to their load time. The results will be readers that find your pages sticker, lower bounce rates, improvements to SEO, and ultimately, higher traffic.
If you’d like to see how Marfeel’s platform can apply all of these best practices, and more to your mobile site, schedule a demo. One of our team will show you the improvements that platform publishing can have on your performance, instantly.