Speed Index measures how quickly the visible part of a page becomes visually complete during a Lighthouse load. It uses frames from a recording of the page and calculates visual progress over time. A lower value means the tested viewport filled sooner.
Speed Index is a lab metric, not a Core Web Vital. It contributes 10% of the current Lighthouse performance score, but it should not be optimized in isolation. The same work that improves early rendering, LCP discovery, and above-the-fold resource scheduling usually improves Speed Index as a consequence.
What Speed Index measures
Lighthouse records the page while it loads, estimates the visual completeness of each frame, and summarizes the area above that progress curve. A page that presents useful structure steadily can outperform one that remains blank and then appears all at once, even if both finish at a similar time.
This makes Speed Index broader than First Contentful Paint, which marks the first qualifying content, and different from Largest Contentful Paint, which follows the largest eligible element. Speed Index describes the tested viewport's overall visual progression.
It does not measure interaction quality, visual stability across the full session, backend capacity, or real-user distributions. Read it with the trace and the other metrics.
How to interpret the thresholds
Chrome's Lighthouse Speed Index documentation currently classifies mobile results as:
| Classification | Mobile Speed Index |
|---|---|
| Good | 0–3.4 seconds |
| Needs improvement | More than 3.4–5.8 seconds |
| Poor | More than 5.8 seconds |
The documented desktop bands are stricter: 0–1.3 seconds is good, more than 1.3–2.3 seconds needs improvement, and more than 2.3 seconds is poor. Always state which device configuration produced a value.
These thresholds classify a Lighthouse run. There is no CrUX Speed Index field metric and no Speed Index Core Web Vital assessment. Use the number to diagnose visual delivery under controlled conditions.
Find the visual delay
Open the Lighthouse run in Chrome DevTools and inspect the filmstrip or Performance trace. Ask when the first useful structure appears and which regions remain incomplete. Common patterns include:
- a blank page until a client application initializes;
- text withheld while a web font downloads;
- a hero region waiting for a late-discovered image;
- a consent layer, animation, or skeleton covering ready content;
- large stylesheets delaying all above-the-fold rendering;
- multiple third-party scripts competing with critical resources.
Use the Network panel to connect each empty or late region to resource timing. The filmstrip identifies where visual progress stalls; the trace identifies why.
Deliver useful HTML earlier
If the initial response contains little more than a root element and script tags, the browser must download and execute JavaScript before it can display meaningful content. Server rendering or static generation can provide headings, navigation, primary copy, and media URLs in the first HTML response.
Keep streaming boundaries deliberate. A shell can paint early, but it should include useful and stable content rather than a full-page placeholder. Avoid fetching data on the client when the server already has everything required to render the initial view.
Reduce avoidable redirects and investigate slow TTFB because the browser cannot begin parsing before HTML arrives. Do not move expensive server work to the client merely to improve TTFB; measure the complete visual path.
Control render-blocking resources
The browser needs CSS for the visible content, but it does not need every page or component style before the first paint. Remove unused CSS, split styles by route where the framework supports it, and keep critical rules small and maintainable.
Defer scripts that do not participate in the initial render. Preserve dependency order and test behavior rather than adding async or defer blindly. A tag manager, chat widget, map, or social embed may be delayed until consent, visibility, or interaction when the product requirements allow it.
Resource hints should be limited to known critical resources. Too many preloads consume bandwidth and can delay more valuable requests.
Schedule images and fonts correctly
For visible images:
- use responsive candidates and an accurate
sizesattribute; - include intrinsic width and height;
- avoid lazy-loading the likely LCP image;
- lazy-load off-screen media;
- avoid hidden duplicate desktop and mobile images that both download;
- compress at a quality appropriate to the content.
Fonts can delay text or change it after paint. Serve WOFF2, remove unused families and weights, subset where appropriate, and choose a font-display strategy intentionally. Preload only font files required by the initial view and ensure the request uses the same URL and CORS mode as the stylesheet.
Reduce JavaScript-driven rendering
A high Speed Index often accompanies substantial startup JavaScript. Use a bundle analyzer and DevTools Coverage to find code delivered to pages that do not use it. Split features at meaningful route or interaction boundaries, and avoid hydrating static content solely to render it.
Long tasks can also prevent the browser from painting frames even after resources arrive. Attribute those tasks in the Performance panel, remove obsolete work, and split essential computation without changing its correctness. Moving suitable computation to a worker can free the main thread, but DOM updates still occur on the main thread.
Third-party code needs an owner and a measured purpose. Compare the visual trace with and without a script in a controlled environment before changing production behavior.
Protect visual stability
Faster visual progress is not useful if content repeatedly moves. Reserve space for images, embeds, banners, and asynchronously loaded widgets. Match skeleton dimensions to final content and avoid inserting notices above already-rendered material.
An opacity or transform reveal can make content appear late without causing layout shift, so CLS alone will not expose every bad loading experience. Inspect the filmstrip and remove decorative reveal delays from principal content.
Validate improvements
Run several Lighthouse tests with the same URL, device mode, cache state, and build. Compare medians and traces instead of selecting the best score. Confirm that the filmstrip shows earlier useful content and that FCP, LCP, TBT, and CLS have not regressed.
Then monitor representative production pages. IndieTools Speed can preserve measurement history, while field Core Web Vitals or your own Real User Monitoring show whether real visitors benefit. A better Speed Index is meaningful when it reflects a visibly faster, stable page rather than a test-specific workaround.
The goal is a clear critical rendering path: prompt HTML, the minimum necessary CSS, correctly prioritized media and fonts, and JavaScript that does not prevent the browser from showing useful content.
