Speed Index is probably one of the most meaningful user-centric metrics when it comes to analyzing a Lighthouse report. It measures how quickly content is visually displayed. Speed Index used to be unitless, but since circa Lighthouse 3, the metric has been measured in seconds.
While metrics like First Contentful Paint measure a single point in time, the purpose of Speed Index is to capture the entire loading process of the visible part of a webpage. In fact, Lighthouse takes a video of the loading process in the background and then calculates the difference between frames.
Generally speaking, Speed Index displays the average time it takes for a page to go from its initial state (blank screen) to a visually complete state. The page can continue loading components and processing data in the background, but if it doesn’t change anything the user sees in the viewport, Speed Index won’t be affected. That’s why this metric is user-centric: it only tracks visual progression, the same way a user will perceive the loading speed.
To give a score to your particular Speed Index (SI) measurement, Lighthouse compares the result to other real website results taken from HTTP Archive.
0-4.3 seconds — Green (fast) — SI score from 75 to 100
4.4-5.8 seconds — Orange (moderate) — SI score from 50 to 74
More than 5.8 seconds — Red (slow) — SI score from 0 to 49
In the previous version of Lighthouse (v5) the metric’s weight was 26.7%. In Lighthouse 6 and 7, Speed Index only affects 15% of the total result. You can play around with values in the interactive Lighthouse Scoring calculator.
Let’s simulate a few different network and website development conditions and see how the Speed Index value changes. For this, I will be using a demo website from one of my previous articles.
To paint the picture rapidly, I will mock the following:
Injecting a render-blocking (non-async) script into the top part of the page
Simulate long downloading times for the script
With this setup, the page will:
Stop rendering on script inclusion and wait for it to load and evaluate
With this in mind, let’s run a Lighthouse audit on this page and check out the numbers.
In the screenshot above, you can see that the Speed Index is in the orange zone with a value of 5.0s.
It’s important to note that this is a visual representation of the page loading process. Our assumptions were right: the page starts loading, then stops after the top bar has been rendered. After that, the rest of the page is displayed quickly.
If we take a look at the contents of the script file, there’s literally nothing (in our case) that absolutely must be downloaded and executed in the top section of the page, so let’s move the script to the bottom of the page — it’s always good practice to defer script loading as much as possible — and run the audit again.
Let’s take a look at the screenshot sequence again. The visual representation of the content gets to the final point quicker, hence improving the perception of speed, and the Speed Index value reflects that.
Earlier in the article, we discussed the importance of optimizing your scripts’ loading times and putting them in the right spot on the page. Now let’s go through the audit and figure out what information is the most pertinent for our purposes.
First, I’d recommend looking at the Diagnostic section, especially these three audits:
Use the minimal required CSS (also called the Critical CSS path) to display the first visible section and defer the rest.
In the Opportunities tab there’s a closely related audit called Eliminate render-blocking resources.
Everything that blocks the rendering process takes its toll on the Speed Index score. Try to put third-party scripts at the bottom of the page or trigger them conditionally.
I’d like to take this moment to advise you not to make improvements solely to see better numbers. First try to determine which functionality and content a potential visitor would need first and foremost.
In this modern age of shortening attention spans, people are getting used to instant content. Even if you have engaging content on your website, poor speed performance can lead to higher bounce rates, hence lower conversion numbers.
Again, if you don’t want to dive into the rabbit hole of script redevelopment right away, I would recommend starting the optimization process by examining the images on your website. To make this easier, Uploadcare has a tool called PageDetox, which will give you a detailed analysis of the images on your website along with the potential network bandwidth that can be saved. Give it a try to see how your website can benefit.