When people say a site “feels fast,” they often mean the screen fills in with meaningful content quickly. Speed Index is Lighthouse’s way of putting a number on that feeling. It is one of five metrics in the Performance section of a Lighthouse report; the others focus on different moments in the load story (for example first paint or interactivity). Together they describe page load from several angles—but Speed Index is explicitly about visual progress.
Lighthouse shows Speed Index in seconds. Lower is better: fewer seconds mean the main content appeared sooner in the filmed load. Think of it as a stopwatch on visual completion, not on total bytes downloaded or every network request finishing.
So what does Speed Index actually measure? During an audit, Lighthouse records a video of the page loading in the browser. It compares successive frames to see how the visible UI evolves—what appears, where, and how much of the viewport looks “complete” over time. From that progression it derives a score using the Speedline module (a Node.js implementation). The math traces back to the original Speed Index from WebPageTest.org, so if you have used WebPageTest before, the idea will feel familiar: same philosophy, baked into Lighthouse.
Your reported Speed Index is not an abstract lab grade in isolation. Lighthouse compares your page’s speed index to real-world data: speed indexes from websites in the HTTP Archive. That context is what turns a raw time into something you can interpret as “roughly fast for the mobile web” or “needs work.”
Visual progress, frame by frame
Lighthouse does not guess Speed Index from one snapshot. It samples the viewport as the page loads—like a short clip from first meaningful content to the last visible layout changes.
That is why work that surfaces the main story earlier—trimming blocking script, taming webfonts, shortening main-thread tasks—often moves Speed Index more than micro-optimizations on assets that never appear above the fold.
Thresholds are different for mobile and desktop—mobile pages are judged a bit more generously in absolute seconds, because conditions are harsher. For mobile, Lighthouse color-codes like this: about 0–3.4 seconds is green (fast), about 3.4–5.8 seconds is orange (moderate), and above about 5.8 seconds is red (slow). For desktop, the bands are tighter: about 0–1.3 seconds is green, about 1.3–2.3 seconds is orange, and above about 2.3 seconds is red. The exact cutoffs can shift slightly as Lighthouse evolves, but the pattern holds: stricter on desktop, roomier on mobile, always aiming at earlier visual completeness.
If you are polishing one lighthouse metric, keep the bigger picture in mind: the overall Performance score blends several signals. Unless you have a targeted goal (for example fixing a regression on one metric), improving the whole score via the largest opportunities in Diagnostics/Diagnostics-style audits is usually the smarter bet than chasing Speed Index alone.
Almost anything that speeds up how soon real pixels stabilize will help Speed Index. In practice Lighthouse highlights a few diagnostic areas that tend to move it a lot: minimizing main-thread work, cutting JavaScript execution time, and keeping text visible while webfonts load (no long stretches of invisible text waiting on a font). Tackle those and you shrink the gap between “blank” and “readable” faster—which is exactly what Speed Index rewards.
Use the Diagnostics section of the report to prioritize: larger estimated savings or higher impact items should pull your overall Performance score more than tiny tweaks. For example, if render-blocking resources show up as the biggest opportunity, resolving that often improves multiple metrics at once, Speed Index included.
In short: Speed Index is a user-centric view of visual readiness during load—grounded in frame-by-frame analysis and real-site baselines. Pair it with the rest of the Performance panel and with Google’s documentation on Lighthouse scoring when you are planning deeper optimizations.