Speed Index Too High: How to Diagnose and Fix It

What this check flags

This fires when Lighthouse reports a Speed Index above its "good" band, meaning the visible part of your page fills in too slowly frame by frame. One thing to be precise about up front: Speed Index is a lab metric from Lighthouse, not one of the three Core Web Vitals, so it isn't itself a ranking signal, but it's a sharp diagnostic that a slow Speed Index almost always drags LCP down with it.

What Speed Index actually measures

Speed Index is different in kind from LCP. LCP marks a single moment, when the one biggest element paints. Speed Index measures the whole progression: Lighthouse films the load, compares each frame to the final rendered state, and computes how quickly the viewport becomes visually complete. A page can post a fine LCP and still have an ugly Speed Index if everything above the fold trickles in piecemeal, one slow chunk at a time. Roughly, under 3.4 seconds is good, 3.4 to 5.8 needs improvement, and above 5.8 is poor, on Lighthouse's mobile profile. Because it's a lab metric it's deterministic, which makes it excellent for catching regressions in CI but useless as the final word on real-user experience.

A real example, and the fix

A page with a decent LCP but a Speed Index of 6.2s. The filmstrip tells the story: white screen for two seconds, then the header pops, then a beat later the body text, then finally the images. Everything is fighting for the main thread because a render-blocking stylesheet and a synchronous script gate the whole paint. Get the critical CSS inline and defer the script:

<!-- Before: paint waits on a full stylesheet round trip + blocking JS -->
<link rel="stylesheet" href="/app.css">
<script src="/app.js"></script>

<!-- After: critical CSS inline, rest loaded async, JS deferred -->
<style>/* inlined above-the-fold rules only */</style>
<link rel="stylesheet" href="/app.css" media="print" onload="this.media='all'">
<script src="/app.js" defer></script>

Now first paint doesn't wait on the network fetching a stylesheet, and the script no longer blocks parsing. The filmstrip goes from four discrete jumps to a smooth fill, and Speed Index drops toward the good band because the visible area completes in one motion instead of four.

Speed Index vs the metrics people confuse it with

How to detect it

1. PageSpeed Insights, Lighthouse section. Scroll past the field-data card into the lab metrics. Speed Index is listed with its color-coded score, and the PageSpeed Insights report links it to the specific opportunities driving it up.
2. Lighthouse in DevTools. The killer feature here is the filmstrip. Run an audit, then look at the frame-by-frame screenshots at the top; you'll see exactly which stretch of the load is blank or janky, which points straight at the render-blocker.
3. CrUX note. Don't bother looking for Speed Index in CrUX or the Search Console vitals report, it isn't collected as field data. It lives only in the lab, which is exactly why you pair it with a field-metric check.
4. WebPageTest. For the richest visual-completeness view, run WebPageTest; it plots visual progress over time and makes a bad Speed Index obvious at a glance.

How to fix it

1. Inline critical CSS, async the rest. Getting above-the-fold styles into the HTML lets first paint happen without a network round trip, the biggest single Speed Index lever.
2. Clear render-blocking resources. Defer non-critical JavaScript so parsing isn't gated, walked through in eliminate render-blocking resources.
3. Prioritize what's visible. Preload the hero and above-the-fold fonts so the important pixels aren't queued behind things nobody can see yet; preload key requests covers it.
4. Trim main-thread work. Long tasks that stall the render also stall the visual fill, so minimizing main-thread work tightens Speed Index and TBT together.

Why the filmstrip beats the number

The single most useful thing about Speed Index is that Lighthouse hands you the film. A raw score of 6.2s tells you the page is slow; the filmstrip tells you where. Two seconds of white screen means something is blocking first paint, a render-blocking stylesheet or a synchronous script. A fast first paint that then sits half-empty for three seconds means the important content is queued behind lower-priority assets, wrong load order, no preload on the hero. A page that fills top-to-bottom in visible steps is fighting the main thread. Read the strip, name the pattern, and you know which fix to reach for, instead of shotgunning every performance opportunity in the report and hoping.

FAQ

Is Speed Index a Core Web Vital?

No. The three Core Web Vitals are LCP, INP, and CLS. Speed Index is a Lighthouse lab metric, useful for diagnosis and CI gates but not part of the ranking signal.

My LCP is good but Speed Index is bad. Which do I care about?

Both, for different reasons. LCP is the ranking-relevant one. But a bad Speed Index means the page still feels slow because it fills in raggedly, and that hurts engagement. Fixing the render-blockers usually improves both at once.

Why isn't Speed Index in my Search Console report?

Because that report is built from field data, and Speed Index is only ever measured in the lab. Chrome doesn't collect it from real users, so it can't appear there.

What's a good Speed Index target?

On Lighthouse's mobile profile, under 3.4 seconds is good. Treat that as a lab benchmark for catching regressions, and confirm the real-world experience with your field metrics.