Speed Index (SI) measures how quickly the content of the viewport becomes visually complete. Lighthouse captures a filmstrip of the load and scores how much of the final above-the-fold image is present at each moment, so a page that paints most of its content early scores better than one that shows everything in a late burst, even when both finish at the same time. It captures visual progress, which is why it can disagree with a single-moment metric like LCP.
What counts as a good Speed Index
The Good / Needs-work / Poor bands sit in the summary panel. SI is lab-only, with no field equivalent, and feeds the PageSpeed score at 10% weight. It is measured under simulated throttling, so it reflects a mid-tier phone rather than the 75th percentile of real visits.
Why we headline this metric instead of LCP
Every audit page on this site compares the original and the accelerated version on Speed Index, and that was a deliberate change. LCP turned out to be bimodal on heavy pages: the browser keeps re-picking the largest painted element, so on a page carrying tens of megabytes of media the winning candidate can differ between two runs of the same URL. One audit in our base printed a headline of “4.2 s → 49.2 s” with no real regression behind it, purely because the two runs settled on different elements.
Speed Index does not have that failure mode. It integrates the whole filmstrip instead of timing one element, so it moves smoothly when the page genuinely changes and stays put when it does not. That property is also why our before/after videos are gated on it: we publish one only when the accelerated version reaches visual completeness in 0.90 or less of the original’s Speed Index, regardless of what the score did.
What keeps the viewport empty
- A render-blocking
<head>. CSS or JavaScript that delays the first paint leaves the screen blank while the browser fetches files. - A hero image or background discovered late. The viewport fills in one late jump rather than progressively.
- Web fonts that hide text until they download, leaving blank space mid-load where readable content should already be.
- Below-the-fold work competing for the network. Off-screen scripts and media take bandwidth from the area the metric is watching.
What prioritising the fold takes away
- Prioritising the visible area starves everything else. Preloading the hero,
fetchpriority="high"and inlined critical CSS mean content just below the fold, and FCP for competing assets, can arrive later. - The same inlining that fills the screen sooner grows the HTML, a TTFB and total-transfer tension.
There is also a server-side trap worth naming, because we walked into it on our own site: compressing HTML harder is not always faster. Switching our marketing site to maximum-quality brotli on shared hosting moved Speed Index from 1.6 s to 3.8 s, because the CPU cost of compressing every request outweighed the bytes saved. Plain gzip took it to 2.2 s and the score to 100.
Filling the fold early, in code
- <link rel="stylesheet" href="/all.css">
+ <style>/* critical, above-the-fold CSS inlined here */</style>
+ <link rel="preload" as="image" href="/hero.webp" fetchpriority="high">
+ <link rel="stylesheet" href="/all.css" media="print" onload="this.media='all'">How we fill the fold early
By inlining critical CSS, preloading the real hero image, swapping in fallback fonts immediately and lazy-loading below-the-fold media, WebSpeed gets visible content on screen progressively rather than in a late burst, which is exactly what Speed Index rewards.