Now Reading: What Is Speed Index? Understanding One of Google’s Key Performance Metrics
-
01
What Is Speed Index? Understanding One of Google’s Key Performance Metrics
What Is Speed Index? Understanding One of Google’s Key Performance Metrics
Two pages can share identical FCP and LCP scores yet feel completely different to load. Speed Index is built specifically to catch that difference here's the formula, a filmstrip breakdown, and an estimator using Lighthouse's actual calculation.
Two pages can share the exact same First Contentful Paint and the exact same Largest Contentful Paint, and still feel completely different to load. One fills in steadily and predictably. The other sits mostly blank, then dumps everything onto the screen at once. Speed Index is the metric built specifically to tell these two experiences apart.
Speed Index measures how quickly the visible, above-the-fold content of a page becomes visually complete during load, expressed in seconds.
Unlike FCP or LCP, it does not mark a single moment in time. It is a calculated score built from comparing video frames captured throughout the entire loading process.
We covered the metrics this one complements in our guides to FCP and LCP. Speed Index looks at the whole visual journey between those two milestones, not just a single point along the way.
or less is Google's "good" Speed Index threshold on mobile devices
weight this metric carries in the overall Lighthouse performance score
or less is the desktop threshold needed for a subscore above 90
How Speed Index Is Actually Calculated
According to Chrome for Developers' official Speed Index documentation, Lighthouse captures a video of the page loading, computes the visual progression between frames, then uses the Speedline Node.js module to generate the final score.
Speed Index Thresholds: Good, Needs Improvement, and Poor
0-3.4s (mobile)
3.4-5.8s
5.8s+
Why This Metric Is Not Available in Field Data
This is a genuinely important limitation to understand. Tap through both perspectives.
According to DebugBear's guide to measuring Speed Index, this metric is reported by Lighthouse and other synthetic testing tools, never as part of CrUX real-user field data.
Calculating it requires capturing and comparing screenshots throughout the entire load, an expensive operation that is simply not practical to run silently on millions of real visitor devices the way Google collects LCP or CLS data.
Speed Index vs. Other Lighthouse Metrics
| Metric | What It Marks | Lighthouse Weight |
|---|---|---|
| FCP | A single moment: first content appears | 10% |
| LCP | A single moment: largest element appears | 25% |
| Speed Index | A calculated score across the entire visual load | 10% |
| TBT | Total main-thread blocking after FCP | 30% |
| CLS | Visual stability throughout the page's lifespan | 25% |
Speed Index Completeness Estimator
Enter the approximate visual completeness percentage of your page at three points during load to estimate how your Speed Index behaves.
Speed Index Completeness Estimator
Based on the same interval-weighted formula Lighthouse uses internally
Enter your completeness percentages above and click estimate.
What Actually Improves Speed Index
According to NitroPack's guide to reducing Speed Index, the core techniques involve reducing JavaScript execution time, minimizing main-thread work, and managing the impact of third-party scripts, the same fixes that help several other loading metrics simultaneously.
According to MigrateLab's complete Lighthouse metrics guide, each metric follows a log-normal scoring curve, meaning early improvements move the needle far more than chasing the last few tenths of a second once a page is already reasonably fast.
Why Progressive Rendering Matters More Than Raw Speed
According to Request Metrics' guide to understanding Lighthouse Speed Index, this metric specifically rewards pages that paint meaningful chunks steadily and punishes pages that download everything first before rendering much of anything.
A page that shows 80% of its content almost instantly, then slowly finishes the remaining 20%, scores better than a page that sits blank and then reveals everything at once, even if both pages technically finish loading at the same total time.
Common Causes of a Poor Score
According to GTmetrix's guide to Speed Index, render-blocking resources are among the most frequent causes, since CSS and synchronous JavaScript loaded before visible content directly delays every frame comparison Lighthouse captures.
According to Nestify's guide to Speed Index for page speed, heavy above-the-fold images without proper compression or modern formats also contribute significantly, since the browser has to finish downloading and decoding them before the visible portion of the page can register as complete.
A third common cause is web fonts that block text rendering until they finish loading.
If custom fonts are not preloaded or given a fallback strategy, the visible page can sit with invisible text for a noticeable stretch, delaying visual completeness even though the underlying HTML has technically already arrived.
Interpreting a Speed Index Result in Context
A single number in isolation tells you less than comparing it against your own site's history or a direct competitor running the same type of page.
According to Unlighthouse's guide to Lighthouse Speed Index, the Lighthouse Score Calculator lets you see exactly how a given value translates into its 10% contribution toward your overall performance score.
Tracking this number across releases, rather than checking it once and moving on, reveals whether a new feature or added script quietly regressed the visual loading experience, even when other metrics appear unaffected.
Setting Up a Repeatable Testing Process
Running a single test and drawing conclusions from it is a common mistake. Network conditions, server load, and even minor CPU throttling variance can shift a single test result by a meaningful margin without anything on the site actually changing.
A more reliable approach runs the same test three to five times and takes the median result, or uses a monitoring tool that automates this repetition on a schedule. This turns a noisy single measurement into a dependable trend line worth acting on.
