Load is not a single moment in time — it’s an experience that no one metric can fully capture. Shubhie Panicker, Google Engineer
Anyone 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.
What is Time to Interactive?
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 V6 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.
How to improve Time to Interactive
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 and lazyload any libraries not used in the initial load.
Minify and compress your files
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
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.
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.
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.