What is Speed Index? How Lighthouse scores it

What Speed Index measures

Most speed numbers are a single moment: when the first thing appeared, when the biggest thing appeared. Speed Index looks at the whole loading process instead. It asks, at every moment during the load, how much of the final picture is already on screen, and turns the answer into one time in seconds. The idea comes from WebPageTest, which introduced it in 2012. Lighthouse does the same thing with its own recording of the load.

Here is a simple example with made-up numbers. Two pages both finish loading at 4 seconds.

Speed Index adds up, for each moment, how much of the page is still missing. Page A: 1 second with all of it missing, plus 3 seconds with half missing, is 1 + 1.5 = 2.5 seconds. Page B: 4 seconds with all of it missing is 4 seconds. Both pages "load" in 4 seconds, but Page A feels faster to a visitor, and its Speed Index (2.5 seconds) says so.

How Lighthouse gets the number

Lighthouse records the page loading as a series of screenshots, compares each one with the final screenshot to work out how complete it is, and calculates the Speed Index from that progression. It uses a small open-source module called Speedline for the calculation. The WebPageTest definition is "the average time at which visible parts of the page are displayed".

Two consequences follow from this method:

• It is a lab metric. Speed Index needs a recording of the load, so it exists only in lab tools such as Lighthouse and PageSpeed Insights. There is no Speed Index in real-user data.
• It depends on the final picture. Progress is measured against how the page looks at the end. A page whose last frame keeps changing, with a slideshow, an autoplaying video or a late pop-up, gives a less reliable number, because the target keeps moving.

The marks Lighthouse uses

Lighthouse turns the time into a score with two control points: the time that earns 90 and the time that earns 50. They were chosen from HTTP Archive data of real websites.

On mobile, Lighthouse's report colors a Speed Index of up to 3.4 seconds green, 3.4 to 5.8 orange and over 5.8 red. The metric carries 10 of the 100 points of the performance score. The comparison with other sites only shapes the scale. Your Speed Index is a measurement of your own page; it is not a ranking against anyone else.

Not a Core Web Vital

Google's Core Web Vitals are LCP, INP and CLS, measured on real visits. Speed Index is not one of them and Google does not use it to decide whether a page passes. It earns its place as a summary: a good Speed Index tells you the page fills in early, and a poor one tells you it stays empty for a while.

Read it together with FCP and LCP. If FCP is quick but Speed Index is poor, the page paints something small early and then waits for the rest. If all three are poor, the whole load is slow.

What Speed Index sees, and what it does not

Speed Index looks at the part of the page that is visible on screen, the viewport, and nothing below it. That has three consequences worth knowing:

• The viewport changes the number. A desktop test has a bigger screen with more to fill in than a phone test, so the same page can score differently for reasons that have nothing to do with speed.
• Below the fold is free. A heavy image far down the page does not affect Speed Index, though it can still affect page weight and data use. What matters is what the visitor sees first.
• It is a time, but not a load time. A Speed Index of 3.4 seconds does not mean the page finished loading in 3.4 seconds. It is a kind of average of when the visible parts appeared, so a page can have a Speed Index lower than its Largest Contentful Paint when most of the screen fills in early and one large image arrives last.

Treat the number as a comparison tool. When you change something and test again with the same settings, a falling Speed Index tells you the screen fills in sooner.

What improves it

Anything that puts visible content on screen sooner:

• A fast server response. Nothing can be drawn before the HTML arrives. See time to first byte.
• No render-blocking files. Inline the styles the first screen needs and load the rest later. See critical CSS and render-blocking resources.
• Optimized images in the first screen. Large, late images are the usual reason a page stays half empty. See image optimization.
• Content in the HTML. A page that arrives as an empty shell and builds its content with JavaScript stays blank until the scripts have run. Putting the main content in the HTML helps every loading metric.
• Less JavaScript work during load. A busy main thread delays painting. The Lighthouse documentation points to minimizing main-thread work, reducing JavaScript execution time and making sure text stays visible while web fonts load.

Why it jumps between runs

Speed Index depends on exactly when each part of the page appears in a recorded video, so it changes from run to run more than a plain timing does. A single test can differ from the next even when nothing changed on your side. Run the test three times and use the median, and compare only tests made with the same settings.

Check your own page

Run the free audit and look at Speed Index in the lab results next to First Contentful Paint and Largest Contentful Paint. A Speed Index far above the other two means the page fills in slowly after the first paint: look at the images and the scripts that load after it.

Sources

• Speed Index in the Lighthouse documentation: what it measures and how Lighthouse scores it.
• Lighthouse performance scoring: how metric scores and weights combine.
• The Speed Index audit source code: the control points quoted above.