GigaOM Radar Edge Platform Leader & Outperformer 2024 | 
Google Lighthouse has become the de facto tool for many websites to measure their performance with a single score: the Lighthouse Performance Score. A new version, Lighthouse 6.0, is now available on npm in Chrome Canary, PageSpeed Insights, and GSC Console. By mid-July, Lighthouse 6.0 will fully roll out to Chrome users in Chrome 84. Now is the time to ensure your site is ready for the new version with a Lighthouse 6.0 score audit.
Lighthouse 6.0 comes with new and depreciated metrics, as well as a new weighting formula to calculate Performance Scores. This new version, along with the announcement that Core Web Metrics will be added to Google’s ranking algorithm in the Google Page Experience update, are clear signs the search giant is emphasizing perceived speed—the speed at which a user perceives a page as loaded. The faster users perceive your site to load, the higher your rank and the more conversions you’ll receive.
The six Lighthouse metrics you need to optimize
Google cares about how users experience the web. Two websites might finish loading at the exact same time, but one may appear to load quicker, based on how content is displayed on the page. While both sites finished loading simultaneously, Google will favor the latter—the site with a faster-perceived performance.
Lighthouse 6.0 scores are based on a weighted average of six user-centric speed metrics. First Contentful Paint (FCP), Speed Index (SI), and Largest Contentful Paint (LCP) measure perceived load speed and hold a combined weight of 55% in a website’s Lighthouse score in version 6. Another 40% of the score is based on metrics measuring responsiveness, another aspect impacting a user’s perception of speed. These include Total Blocking Time (TBT) and Time to Interactive (TTI). The last 5% of the score is based on a metric that measures visual stability, called Cumulative Layout Shift (CLS).
First Meaningful Paint (FMP) and First CPU Idle (FCI) from the Lighthouse 5.7 score were replaced by better metrics to measure speed from a user-centric perspective. These are the Largest Contentful Paint (LCP) and Total Blocking Time (TBT) in Lighthouse 6.0.
| Lighthouse 5.7 | Weight | Lighthouse 6.0 | Weight |
|---|---|---|---|
| First Contentful Paint (FCP) | 20% | First Contentful Paint (FCP) | 15% |
| Speed Index (SI) | 27% | Speed Index (SI) | 15% |
| First Meaningful Paint (FMP) | 7% | Largest Contentful Paint (LCP) | 25% |
| First CPU Idle (FCI) | 13% | Total Blocking Time (TBT) | 25% |
| Time to Interactive (TTI) | 33% | Time to Interactive (TTI) | 15% |
| - | - | Cumulative Layout Shift (CLS) | 5% |
Here are the six-speed metrics to focus on as you audit your website in preparation for Lighthouse 6.0. The metrics are laid out in the order they are measured as the page loads.
A simplified checklist covering the speeds you should aim to deliver and optimization techniques per metric are made available at the bottom of this article.
First Contentful Paint
FCP marks the first point when a user can see any page content on the screen. This content includes text, images, graphics, or SVG files. FCP had a weight of 20% in Lighthouse 5.7 but only held 15% weight over your Lighthouse 6.0 score.
In the filmstrip above, the FCP for the first-page load is measured at 0.6 seconds. This is when content first appears on the homepage for TheTieBar.com, but you’ll notice it’s not when all of the content is visible. This is an important distinction between the first and largest contentful paint. LCP is measured at 0.9 seconds when the above-the-fold content is displayed.
As you go through your Lighthouse 6.0 score audit, make sure your pages average FCPs of 2 seconds or less, as this is the metric’s threshold for the 75th percentile and is considered fast by Google. FCPs between 2 and 4 seconds is considered moderate speeds, and FCPs exceeding 4 seconds drop below the 50th percentile and are classified as slow.
If you find FCPs loading too slow, it can be due to one or more of the following:
- Too many render-blocking resources
- Large CSS files
- Lack of secure connections to third-party origins
- Long server response times
- Multiple page redirects
- Uncached static resources
- Excessive DOM size
To optimize your FCP, consider the following:
- Inline critical resources, defer non-critical resources, and remove anything unused to reduce the impact of render-blocking URLs.
- Remove all the unnecessary characters from the CSS to size down files.
- Use preconnect to establish early connections to important third-party origins.
- Reduce server response times by optimizing the server’s application logic or upgrading your server hardware to have more memory.
- Avoid more than a 1-page redirect.
- Use HTTP caching to cache static resources.
- Have less than 1,500 nodes total, a depth of fewer than 32 nodes, and a parent node with less than 60 child nodes to decrease DOM size.
Speed Index
SI measures the visual progression of a page load and calculates an overall score for how quickly the content is painted. In Lighthouse 5.7, SI had 27% weight over a website’s Performance Score. In Lighthouse 6.0, this is semi-diminished, influencing 15% of a page’s Performance Score. Google still sees this as a key perceptual metric, as a page with a slow image display can be perceived as janky.
Lighthouse measures SI by capturing a filmstrip of a page as it loads in the browser and analyzing the visual progression frame-by-frame. The average time at which visible parts of the page are displayed determines the SI. This metric will differ based on device screen sizes.
As you go through your Lighthouse 6.0 score audit, aim for SIs in 4.3s or less. This speed ranks in the 75th percentile and is considered fast by Google. Pages with SIs between 4.3 and 5.8 seconds are moderate, and SIs slower than 5.8 seconds drop below the 50th percentile and are considered slow.
Slower SI times tend to stem from the following:
- Load times on the main thread exceed 4 seconds
- JavaScript execution time exceeds 3.5 seconds
- Large font files cause a flash of invisible text (FOIT).
To cut SI times down, consider the following:
- Implement code-splitting, remove unused code and compress code to reduce the load on the main thread and JavaScript execution time.
- Ensure text remains visible during Webfont load to avoid FOIT.
Largest Contentful Paint
LCP is a new metric added to Lighthouse 6.0 and receives 25% weight in a site’s Performance Score. LCP replaces First Meaningful Paint (FMP) from Lighthouse 5.7. Although both metrics measure the time the largest content element is displayed, FMP is notorious for producing inconsistent results and can only be standardized in certain web browsers.
LCP measures when the largest content element is fully visible on the screen. Content elements measured include block-level elements, images (including images inside SVG files), and videos. This is an extremely important metric for eCommerce websites as it marks the point in time in which most users perceive the page as fully loaded and are more likely to make a purchase.
In the example above, the LCP is 0.9 seconds—when the main image is fully painted. This metric captures a distinct moment when a user perceives a page fully loaded, yet content may still be loading below the fold.
Top performing websites, like those on Layer0 (now Edgio), deliver LCPs in under 1 second. LCPs up to 2.5 seconds are considered fast and rank in the 75th percentile for this metric. LCPs between 2.5 seconds and 4 seconds are considered moderate, needing improvement, and LCPs exceeding 4 seconds fall below the 50th percentile and are considered slow by Google.
Slow LCPs usually stems from one or more of the following:
- Slow server response times
- Render-blocking JavaScript and CSS
- Long resource load times
- Client-side rendering issues
If you find slower than the desired LCPs during your Lighthouse 6.0 score audit, consider the following:
- Optimize server response times by routing traffic to the closest CDN available, caching assets, serving HTML pages cache-first, and establishing third-party connections early.
- Reduce CSS by removing unnecessary CSS, defer non-critical CSS, and inline critical CSS. Reduce JavaScript blocking time by compressing JavaScript files.
- To reduce resource load times, optimize and compress image and text files, and preload important resources.
- Optimize client-side rendering by using server-side rendering and pre-rendering.
Total Blocking Time
TBT replaces FCI from Lighthouse 5.7, which used to hold 13% weight. In Lighthouse 6.0, TBT measures page responsiveness and will account for 25% of a Performance Score. TBT measures the severity of how non-interactive a page is before it becomes reliably interactive.
You know these painful instances: You’re waiting for a page to load, and then finally—it looks ready. You tap the product you want to see, but nothing happens. Do you tap again? This waiting period is known to literally cause stress in consumers. Essentially, TBT is the length of time a consumer feels that stress due to a page’s non-interactivity.
Source: web.dev
This metric is measured by calculating the sum total of “blocked” time (tasks that take longer than 50ms) between the first content element displayed (FCP) and when a user can fully interact with the page (TTI). For example, in the image above, there are five tasks taking place in the main thread, but only three of them exceed 50ms. The first by 200ms, the second by 40ms, and the third by 105ms. TBT is (200+40+105) 345ms.
A task taking longer than 50ms will be long enough for a user to notice and perceive the page as sluggish, or worse, inactive, and lead them to leave. To avoid this, aim for a TBT under 300ms to be considered fast. TBTs between 300ms and 600ms are considered moderate speeds and need improvement. TBTs slower than 600ms fall below the 50th percentile and are considered slow.
Long tasks are typically caused by one or more of the following:
- Third-party code that blocks the main thread for 250ms or longer
- JavaScript execution time takes more than 3.5 seconds
- The main thread is busy for longer than 4 seconds during the load
- A high volume of network requests and large transfer sizes
To improve this metric, consider the following:
- Efficiently load third-party JavaScript using the async or defer attributes on script tags, establish early connections to important third-party origins and use lazy-loading.
- To speed up JavaScript execution and reduce the load on the main thread, implement code-splitting, remove unused code and compress code.
- Optimize CSS and JavaScript to reduce resource counts and transfer sizes.
Time to Interactive
TTI is the third metric carried over from Lighthouse 5.7, but Google has decreased its weight from 33% to 15% in Lighthouse 6.0. TTI is a companion metric to TBT, measuring how long a page takes to become reliably or fully interactive. Lighthouse considers a page reliably interactive when the first content element is displayed, its initial scripts (if any) have loaded, and it can respond to user input within 50ms.
To a user, slow TTIs can feel like a page is inactive or broken. Although a page looks interactive, it’s not actually because the main thread is blocked (measured by TBT). As you audit your website for Lighthouse 6.0, aim for TTIs in 5.2 seconds or less to be considered fast. TTIs between 5.2 and 7.3 seconds are considered moderate speeds, and TTIs slower than 7.3 seconds are considered slow and will impact consumers’ willingness to stay on site.
If your Lighthouse 6.0 score audit shows poor TTI speeds, it can be due to one or more of the following:
- Large payload sizes and long script parse time
- Long resource load times
- Third-party code blocks the main thread for 250ms or longer
- Critical request chains
- Slow main thread speed and JavaScript execution time
- High resource counts or large transfer sizes
Reducing TTI time can be done by optimizing your JavaScript. This includes:
- Reduce and compress JavaScript files to reduce payload sizes and script parse time.
- Preload requests and/or add preconnect for faster load times.
- Efficiently load third-party JavaScript by using the async or defer attributes on script tags and by using lazy-loading.
- Reduce the effect of critical request chains on performance by reducing the number of critical resources and optimizing the order in which the remaining resources are loaded.
- Implement code-splitting, remove unused code and compress code to reduce the load on the main thread and JavaScript execution time.
- Optimize CSS and JavaScript to reduce resource counts and transfer sizes.
Cumulative Layout Shift
CLS is the third new metric introduced in Lighthouse 6.0, and it is the only one not to replace any metric from Lighthouse 5.7. CLS accounts for the last 5% of your Lighthouse 6.0 score, and it measures visual stability.
This metric measures how often users experience unexpected layout shifts. You’ve experienced this before: You’re about to tap a product, and bam, suddenly, you tap something else on the page because the elements shifted. These experiences can be quite annoying and seen as janky to a user.
CLS is measured by the sum total of all individual layout shift scores for each unexpected layout shift that occurs during the entire lifespan of the page. A good CLS is lower than 0.1 and ranks in the 75th percentile for performance. A CLS between 0.1 and 0.25 is considered moderate, and any measurement greater than 0.25 falls below the 50th percentile and is considered slow by Google.
If you find a poor CLS during your Lighthouse 6.0 score audit, it’s likely due to one of the following:
- An image or video resizing itself
- A font that loads late and is displayed larger or smaller than intended
To improve this metric, consider the following:
- Include exact dimensions on your images and video elements
- Avoid popup ads or banners
- Avoid font causing FOIT/FOUT
Lighthouse scores show you what Google thinks of your site
A page’s Lighthouse Performance Score indicates how Google perceives the page in terms of speed. Each metric in Lighthouse 6.0 reflects Google’s best attempt at measuring how users perceive speed. If a score falls below standards, it will be perceived as slow—not just by users but by the search giant itself, resulting in negative impacts on revenue and SEO.
Google ranks sites faster and higher on the search engine results page. Beyond SEO, site speed has been found to significantly impact conversions and revenue. Amazon, for example, found a 1-second lag in page load could cost the company a $1.6B loss a year.
Bottom line
This latest version of Lighthouse demonstrates the search giant’s emphasis on perceptual speed metrics. The scoring metrics in Lighthouse 6.0 attempt to measure how quickly visitors perceive your page as fully loaded (even if it is still running processes in the background).
Three metrics, First Contentful Paint, Speed Index, and Largest Contentful Paint, measure perceived load speed and accounted for 55% of your Performance Score. Aim for FCPs of 2 seconds, LCPs of 2.5, and SIs of 4.3 seconds or less.
Another 40% of a Performance Score is based on perceptual metrics measuring a page’s responsiveness. These include Total Blocking Time and Time to Interactive. A fast Lighthouse 6.0 score audit will show a TBT in under 300ms and TTI in under 5.2 seconds, or a user will perceive your site as janky.
Finally, no one likes to text or images jumping in and out of the screen. Cumulative Layout Shift is the sixth metric to account for in your Lighthouse 6.0 audit. Aim for CLS measurements lower than 0.1, and you’ll receive the full 5% of the weight it holds in your Performance Score.
To receive a simple checklist covering the speeds you should aim to deliver in your Lighthouse 6.0 Score audit, along with optimization techniques per metric, please fill out the form below.
