Speed Index is a lab metric in web performance that expresses how quickly the visible area of a page fills with content during loading. It is reported in milliseconds, and a lower value means the page looked complete sooner. Unlike milestone metrics that record a single moment, Speed Index summarizes the entire visual progression from navigation to visual completeness.
The metric was introduced with the WebPageTest tool and later adopted by Lighthouse, where it remains one of the scored lab metrics. It is not a Core Web Vital and is not collected from real users, but it is valuable for judging whether a page renders progressively or all at once.
How Speed Index is calculated
The test tool records the viewport as a sequence of frames while the page loads. For each frame it estimates visual completeness, a percentage that describes how close the frame is to the final rendered state. Speed Index is then the area above the visual progress curve: the sum, over time, of the fraction of the page that is still incomplete.
Expressed as a formula, Speed Index equals the integral of (1 minus visual completeness) over the load duration. A page that is 0 percent complete for two seconds and then jumps to 100 percent scores about 2,000. A page that reaches 80 percent at 500 ms and the rest at two seconds scores far lower, because most of the incomplete area disappears early.
| Method | How completeness is measured | Typical use |
|---|---|---|
| Histogram comparison | Color histograms of each frame against the final frame | Original WebPageTest approach |
| Structural similarity (SSIM) | Perceptual similarity of image structure | Perceptual Speed Index variants |
| Paint events | Painted rectangles reported by the browser | Faster estimates without video |
Because completeness is measured against the final frame, elements that keep changing, such as carousels, video or rotating banners, distort the result. Test configurations often freeze or exclude such content to keep the metric meaningful.
Thresholds and value ranges
Speed Index values depend heavily on device class, network throttling and viewport size, so they are only comparable within the same test configuration. Lighthouse publishes score curves for its default emulated mobile profile, which applies a slow CPU and network throttling.
| Rating | Speed Index | Interpretation |
|---|---|---|
| Good | 0 to 3.4 s | Content appears quickly and progressively |
| Needs improvement | 3.4 to 5.8 s | Noticeable empty or partial phases |
| Poor | Above 5.8 s | Long blank periods or late, sudden rendering |
In the Lighthouse performance score, Speed Index carries a weight of about 10 percent in recent versions, smaller than Largest Contentful Paint, Total Blocking Time and Cumulative Layout Shift. Desktop runs use considerably stricter thresholds, reflecting faster hardware and network assumptions.
Speed Index compared with other loading metrics
Speed Index complements milestone metrics. FCP and LCP tell when specific paints occur; Speed Index tells how the rendering progressed between them. Two pages with identical LCP can have very different Speed Index values if one renders in stages and the other stays blank until the end.
| Metric | What it captures | Field data available |
|---|---|---|
| Speed Index | Overall pace of visual population | No, lab only |
| FCP | First text or image painted | Yes |
| LCP | Largest visible element painted | Yes, Core Web Vital |
| TTFB | Server response start | Yes |
| CLS | Unexpected layout movement | Yes, Core Web Vital |
| INP | Responsiveness to interactions | Yes, Core Web Vital |
A slow TTFB pushes every later visual event back, so it raises Speed Index directly. Conversely, an excellent TTFB does not guarantee a good result if render-blocking CSS and fonts keep the viewport empty.
Improving Speed Index in practice
Speed Index rewards getting meaningful pixels on screen early. The most effective changes are those that let the browser paint above-the-fold content before every resource has arrived.
| Lever | Effect on Speed Index | Caution |
|---|---|---|
| Inline critical CSS | Removes a render-blocking request | Keep it small, typically under 14 KB |
| Preload key resources | Hero image and fonts arrive earlier | Excess preloads compete for bandwidth |
| font-display: swap | Text paints before web fonts load | Can cause visible font swapping |
| Server-side rendering | HTML arrives with visible content | Hydration cost may hurt INP |
| Lazy loading below the fold | Frees bandwidth for visible content | Never lazy load the hero image |
Deferring non-critical JavaScript helps because parser-blocking scripts delay first render. Reducing main-thread work during startup also matters, since layout and paint cannot happen while long tasks occupy the thread.
Limitations and misreadings
Speed Index measures pixels, not usefulness. A page that paints a large decorative background immediately can score well while its actual content arrives late, and skeleton screens can flatter the metric without helping the reader.
- Run-to-run variance is significant; compare medians of several runs, not single tests.
- Viewport size changes results, because only the visible area counts.
- Animated content inflates values by delaying visual completeness.
- No real-user equivalent exists, so field monitoring must rely on FCP and LCP instead.
The practical consequence is that Speed Index works best as a regression and diagnosis signal in controlled lab tests, for example in a continuous integration pipeline with a fixed device profile. It should be read together with the filmstrip view of the same run, which shows exactly which phases were blank or partial, and with field metrics that reflect what real visitors experience on their own devices and networks.
The simple explanation
Imagine watching a picture appear on a screen, piece by piece. Speed Index answers one question: how long did the screen look unfinished? If most of the picture shows up right away, the score is low and good. If the screen stays blank and everything appears at the last moment, the score is high.
That is why two pages that finish at the same time can feel very different. The page that shows something useful early feels faster, and Speed Index puts a number on that feeling.
How it is used in practice
A news publisher notices that its article pages have an acceptable LCP of about 2.4 seconds on emulated mobile tests, yet readers describe them as slow. A Lighthouse run shows a Speed Index of 5.1 seconds, and the filmstrip reveals a blank white viewport for most of the load.
The cause is a render-blocking stylesheet of 180 KB and two web fonts with invisible text until they load. The team inlines about 12 KB of critical CSS, loads the rest asynchronously and switches the fonts to font-display: swap.
After the change, headlines and the lead paragraph appear within the first second. The median Speed Index drops to about 2.6 seconds across five runs, LCP stays roughly unchanged, and the filmstrip now shows a steady, progressive render instead of a sudden late reveal.