Speed Index is a Lighthouse lab metric that estimates how quickly the visible part of a page fills in during loading. A lower number means the tested viewport became visually complete sooner in that run. It is useful when a page stays blank or appears in fragments, but it does not tell you by itself when a visitor could use the page. Speed Index is not one of the three Core Web Vitals.
To improve it, inspect the loading filmstrip, identify what keeps the initial view empty, fix that bottleneck, and compare repeated tests under similar conditions. For a broader action plan, see our page speed optimization guide. Google's Lighthouse Speed Index documentation explains how the metric is derived.
What Lighthouse measures
Lighthouse captures the page's loading progress and estimates visual completeness over time. Imagine two pages with the same first visible element and the same final appearance. One gradually shows the main content while the other displays a blank area until a large image arrives. The second can have a worse Speed Index because more of the tested viewport stayed incomplete for longer.
The metric depends on the particular URL, viewport, page state, and lab conditions. It is not a whole-site average. A consent banner, personalized content, animation, or late-loading advertisement can change the visual sequence. Always note what was actually visible in the test before treating a change in the number as a product improvement.
Lighthouse scores Speed Index as one part of its lab performance assessment. Do not infer a guaranteed search-ranking change from moving this metric alone. Focus first on whether important content is useful to real visitors.
Speed Index versus FCP, LCP, and INP
| Metric | Main question | Where it is most useful |
|---|---|---|
| First Contentful Paint (FCP) | When did the first text or image appear? | Detecting an initially blank page |
| Speed Index | How quickly did the initial viewport fill in? | Diagnosing visual progression in a lab run |
| Largest Contentful Paint (LCP) | When did the largest eligible visible content appear? | Understanding main-content loading |
| Interaction to Next Paint (INP) | How responsive was the page to user interactions? | Real-user responsiveness |
A fast FCP can coexist with a slow Speed Index: perhaps a small header appears quickly while the article or product image arrives much later. Conversely, an attractive early screenshot does not prove that controls respond promptly. Use our FCP guide and Core Web Vitals guide to interpret those questions separately.
INP, LCP, and CLS are Core Web Vitals; Speed Index is a lab diagnostic. PageSpeed Insights may show both field and lab data, but it does not report a real-user Speed Index distribution in the Core Web Vitals panel.
Diagnose the delay from the filmstrip
Run the exact affected URL in PageSpeed Insights and open the Lighthouse filmstrip or trace. Ask what occupies the viewport before the page appears: blank background, unstyled text, a placeholder, or a partial hero. Then inspect the related network and rendering diagnostics. The cause should come from the evidence on that page, not a generic list of “speed tips.”
Illustrative example: A service page paints its navigation at 0.9 seconds but leaves the main hero blank until 4.2 seconds. A large image is requested late through CSS. FCP may look reasonable while Speed Index and LCP remain poor. The likely task is to inspect how that hero is discovered and sized, not to optimize an unrelated footer script. The times illustrate a reading pattern; they are not Screpy measurements.
Other patterns need different fixes. If text is invisible until a web font loads, review font-display and critical font delivery. If render-blocking styles hold the whole viewport, remove unused CSS or deliver essential styles sooner; CSS optimization is one possible part. If early JavaScript prevents rendering, identify the blocking work and defer what is unnecessary for the first view. If transfers are large, check text compression and image sizing. Avoid changing all of these at once, or the next test will not tell you which change helped.
Compare tests without mistaking noise for progress
Record the URL, mobile or desktop configuration, page state, test date, and the specific visual problem. Run the baseline more than once. After one focused change, repeat comparable tests and inspect the filmstrip, Speed Index, FCP, and LCP together. If the new layout is unstable or the booking button stops working, a better lab number is not a successful fix.
Lab runs vary with server response, third-party resources, caching, and the test environment. Use a range of repeated results, not only the best run. Then check real-user LCP, INP, and CLS where field data is available. Screpy's page speed monitoring can help watch repeated performance checks, but a lab trend and a field-data trend answer different questions.
Prioritize pages that matter to users and the business. The exact Speed Index threshold used in Lighthouse scoring can change with tool versions, and the metric does not replace Core Web Vitals. The practical goal is that meaningful content appears promptly and the page remains usable.
FAQ
Is Speed Index a Google ranking factor?
Google documents Core Web Vitals as part of its page-experience signals; Speed Index is not listed as a standalone Core Web Vital. Treat it as a diagnostic for visual loading, not a direct ranking promise.
What is a good Speed Index?
Compare your current Lighthouse result with its scoring guidance under the tested configuration. A universal number detached from device and network conditions is less useful than a repeatable baseline and a visible improvement.
Why does it change between runs?
The simulated environment, server, cache, ads, content, and third-party requests can vary. Run comparable tests several times and inspect what changed visually.
Should I fix Speed Index before LCP?
Fix the user-visible bottleneck. If the main element arrives late, LCP can point directly to it; Speed Index can reveal that the rest of the viewport also remains incomplete.
Does Speed Index show how fast a page responds to taps?
No. It describes visual loading in a lab run. Use responsiveness metrics and direct interaction testing for taps and clicks.