Speed Index

Speed Index measures how quickly the visible part of your page fills with content while it loads. Instead of a single moment, it rates the whole loading sequence as a visitor sees it. A low Speed Index means the viewport looks complete early; a high one means people watch a blank or half-built screen for a long time.

From PerfDelta's measurements: In the mobile lab test, 5% of 5,498 home pages have a good Speed Index and 77% a poor one. The median is 8657 ms, with the middle half between 6039 ms and 12347 ms. More in the data section below.

What Speed Index measures: visual progress over time

During a Lighthouse test the browser records a filmstrip of the load, a series of screenshots of the viewport. Each frame is compared with the final state of the page to work out how visually complete it is, from 0 % (nothing yet) to 100 % (looks finished). Plotting that completeness over time gives a visual progress curve. Speed Index is the area above that curve: the longer the screen stays incomplete, and the more of it stays incomplete, the higher the number. It is expressed in seconds, and lower is better.

A simple example shows why this is useful. Two pages both look finished after 3 seconds:

• Page A shows nothing at all for 3 seconds, then everything appears at once. It spends 3 full seconds at 0 % complete, so its Speed Index is 3.0 s.
• Page B paints its header, text and layout after 1 second, which already makes it 80 % complete, and the remaining 20 % (a photo) arrives at 3 seconds. It spends 1 second fully incomplete and 2 seconds 20 % incomplete: 1 + 2 × 0.2 = 1.4 s.

Both pages have the same finish time, yet Page B feels far faster, and Speed Index captures exactly that difference.

Good Speed Index thresholds in Lighthouse

Lighthouse scores Speed Index with different thresholds for its two test profiles, because the mobile test runs on a throttled connection and a slower simulated CPU:

Profile	Good	Needs improvement	Poor
Mobile	3.4 s or less	3.4 to 5.8 s	more than 5.8 s
Desktop	1.3 s or less	1.3 to 2.3 s	more than 2.3 s

Speed Index accounts for 10 % of the Lighthouse performance score, the same weight as First Contentful Paint. Largest Contentful Paint and Cumulative Layout Shift carry 25 % each and Total Blocking Time 30 %.

Speed Index is lab-only and not a Core Web Vital

Speed Index only exists in lab tools. The Chrome UX Report has no field equivalent, because real browsers do not record filmstrips of every page view. You will therefore find it in the Lighthouse section of PageSpeed Insights, never in the field data block, and it plays no direct role in Google's page experience signals. Its value lies in diagnosis.

How Speed Index relates to FCP and LCP

The three loading metrics describe different points on the same curve:

• First Contentful Paint marks where the curve starts to rise. Until the first paint the viewport is 0 % complete, so a slow FCP pushes Speed Index up directly.
• Largest Contentful Paint marks when the biggest element appears. If that element is a hero image covering half the screen, a late LCP keeps a large share of the viewport incomplete and raises Speed Index as well.
• Speed Index summarises everything in between: how much of the screen is filled at each moment between the first paint and visual completeness.

In practice most fixes for FCP and LCP also lower Speed Index. The cases where Speed Index stays poor despite decent FCP and LCP values usually involve content that keeps changing after it first appears.

Causes of a slow Speed Index

• Render-blocking CSS and JavaScript. Stylesheets and synchronous scripts in the head stop the browser from painting anything.
• Late web fonts. If text is hidden until the font file arrives, large text areas count as incomplete even though the HTML is already there.
• Big hero images. A heavy image that fills much of the viewport and loads late keeps that area empty.
• Client-side rendering. When the HTML contains only an empty container and JavaScript builds the page, nothing useful appears until the bundle has downloaded, parsed and run.
• Animations and carousels. Sliders that rotate, fade-in effects and animated banners keep changing the viewport. Because every frame is compared with the final frame, a screen that is still moving never counts as complete.
• Loading spinners and skeletons. A spinner paints early but looks nothing like the finished page, so it adds little visual progress while the real content waits.

How to improve Speed Index

1. Clear the critical rendering path

Inline the CSS needed for the above-the-fold area, load the rest without blocking, and defer scripts that are not needed for the first render. The full method is in the guide to eliminating render-blocking resources.

<style>/* critical CSS for header and hero */</style>
<link rel="preload" href="/css/main.css" as="style" onload="this.rel='stylesheet'">
<script src="/js/app.js" defer></script>

2. Prioritise above-the-fold content

Make sure the browser fetches what fills the first screen before anything else. Give the hero image a high fetch priority, never lazy-load it, and size it correctly for the viewport. Lazy-load images further down instead.

<img src="/img/hero-1200.webp"
     srcset="/img/hero-800.webp 800w, /img/hero-1200.webp 1200w"
     sizes="100vw" width="1200" height="600"
     fetchpriority="high" alt="Product overview">

3. Show text immediately with font-display

Let text render in a fallback font while the web font loads. Preloading the one or two fonts used above the fold shortens the swap further.

@font-face {
  font-family: "Brand Sans";
  src: url("/fonts/brand-sans.woff2") format("woff2");
  font-display: swap;
}

4. Render on the server

Send HTML that already contains the visible content. Server-side rendering or static generation lets the browser paint the page before JavaScript runs; hydration can then attach interactivity afterwards.

5. Avoid layout-altering animations during load

Let carousels start on a static first slide and only begin rotating after the page has loaded. Drop entrance animations that fade or slide the main content into view, and replace full-page spinners with the real content or a server-rendered version of it.

window.addEventListener('load', () => {
  setTimeout(() => carousel.start(), 3000);
});

Speed Index in WordPress, Shopify and React/Next.js

WordPress: slider plugins and page builders with entrance animations are frequent causes. Choose a static hero, disable animations on above-the-fold sections and use a performance plugin that generates critical CSS and defers scripts. Test menus and forms afterwards.

Shopify: slideshow sections on the home page and app scripts injected into the theme slow the visual build-up. Use a single image banner instead of an autoplaying slideshow and remove apps you no longer use, since their scripts often stay in the theme.

React and Next.js: a purely client-rendered React app shows an empty root element until the bundle runs. Next.js renders on the server or at build time by default, so keep above-the-fold components out of client-only code paths and use the framework's image component with priority for the hero.

Common mistakes with Speed Index

• Lazy-loading the hero image, which delays exactly the area Speed Index weighs most.
• Hiding the whole page until JavaScript has finished, for example with an opacity transition on the body.
• Judging the score from one run. Lab results vary between runs, so compare several before drawing conclusions.
• Optimising only the home page while other templates keep heavy sliders or client-side rendering.

How to verify your Speed Index

Open the Lighthouse report in PageSpeed Insights and look at the filmstrip of screenshots below the metrics. It shows directly whether the screen stays blank, fills gradually or keeps changing. In Chrome DevTools, the Performance panel with screenshots enabled gives a more detailed view frame by frame. Compare filmstrips after each change, not only the number.

PerfDelta tests several pages of your site on mobile and desktop and shows lab and field data side by side, so you can see whether Speed Index is a problem across templates or on a single page. PerfDelta also lists the Lighthouse opportunities with estimated savings and the affected files, and links each recommendation to the matching guide.

Frequently asked questions

What is a good Speed Index?

In Lighthouse, a Speed Index of 3.4 seconds or less is good on mobile and more than 5.8 seconds is poor. On desktop, 1.3 seconds or less is good and more than 2.3 seconds is poor.

How is Speed Index calculated?

Lighthouse records a filmstrip of the load and compares each frame with the final page to measure visual completeness. Speed Index is the area above that visual progress curve, so it grows the longer the viewport stays incomplete.

Is Speed Index a Core Web Vital?

No. Speed Index is a lab metric used in the Lighthouse performance score with a weight of 10 %. It has no field equivalent in the Chrome UX Report and is not part of the Core Web Vitals.

Why is my Speed Index poor when FCP and LCP are good?

Usually because the viewport keeps changing after the main content appears. Rotating carousels, entrance animations and loading spinners prevent the screen from matching the final frame, which keeps visual completeness low.

How do I improve Speed Index?

Remove render-blocking resources from the critical path, prioritise the above-the-fold content, use font-display: swap for web fonts, render the visible content on the server and avoid animations that change the viewport during load.

Why does Speed Index change between tests?

Lab runs vary with network conditions, server response and third-party content. Compare several runs and look at the filmstrip to see whether the visual build-up has really changed.