Speed Index: How Quickly Do Your Users Actually See Content?
Speed Index measures how fast the visible area of a page is populated. Learn how it's calculated, what good scores look like, and how to improve it.
Most performance metrics measure specific moments — when the first pixel appears (FCP), when the largest element renders (LCP). But Speed Index measures something different: how quickly the entire visible area of your page is populated with content.
What Speed Index Measures
Speed Index captures the visual progression of a page load. It analyzes video frames of the loading process and calculates how quickly the viewport goes from blank to fully rendered.
A page that renders progressively (header first, then content, then sidebar) will have a better Speed Index than a page that stays blank for 3 seconds and then renders everything at once — even if both pages finish loading at the same time.
Speed Index Thresholds
| Speed Index | Rating |
|---|---|
| ≤ 3.4s | Good |
| 3.4–5.8s | Needs Improvement |
| > 5.8s | Poor |
How Speed Index Is Calculated
- Lighthouse captures screenshots of the page loading process at regular intervals
- For each frame, it calculates what percentage of the viewport has been painted
- It plots "visual completeness" over time
- Speed Index is the area above the curve — the area between the completeness curve and the 100% line
Lower area = faster visual completion = better Speed Index.
Visual Example
Page A (Good Speed Index):
Time: 0s 0.5s 1s 1.5s 2s
Visual: 0% 40% 75% 95% 100%
Page B (Poor Speed Index):
Time: 0s 0.5s 1s 1.5s 2s
Visual: 0% 0% 0% 10% 100%
Both pages reach 100% at 2 seconds, but Page A feels much faster because content appears progressively.
Why Speed Index Matters
Speed Index measures perceived performance — how fast the page feels to users. This matters because:
- Users make judgments about page quality within the first second
- Progressive rendering keeps users engaged during loading
- A blank screen triggers the "is it broken?" response
- Early visual feedback reduces perceived wait time by up to 40%
Speed Index vs. Other Metrics
| Metric | What It Measures |
|---|---|
| FCP | First pixel of content |
| LCP | Largest content element |
| Speed Index | Overall visual progression |
| TTI | When page becomes interactive |
Speed Index fills a gap the other metrics miss. You could have a fast FCP (small text renders early) and a fast LCP (hero image loads quickly) but still have a poor Speed Index if the rest of the viewport loads slowly.
How to Improve Speed Index
1. Eliminate Render-Blocking Resources
CSS and synchronous JavaScript in the <head> block the browser from rendering anything:
<!-- Bad: blocks rendering -->
<link rel="stylesheet" href="/styles.css">
<script src="/app.js"></script>
<!-- Better: non-blocking -->
<link rel="stylesheet" href="/critical.css">
<link rel="preload" href="/styles.css" as="style" onload="this.rel='stylesheet'">
<script src="/app.js" defer></script>
2. Inline Critical CSS
Extract the CSS needed for above-the-fold content and inline it:
<head>
<style>
/* Critical CSS for initial viewport */
.hero { background: #1a1a2e; min-height: 100vh; }
.nav { position: fixed; top: 0; }
</style>
<link rel="preload" href="/full-styles.css" as="style">
</head>
3. Prioritize Visible Content
Load above-the-fold content first. Defer everything below the fold:
- Use
loading="lazy"on below-fold images - Use
fetchpriority="high"on hero images - Defer non-critical JavaScript with
deferor dynamic imports
4. Use Server-Side Rendering or Static Generation
Client-rendered pages (SPA) typically have poor Speed Index because the page is blank until JavaScript downloads, parses, and executes.
SSR and SSG send fully-rendered HTML, giving the browser content to display immediately.
5. Optimize Web Fonts
Custom fonts can block text rendering. Use font-display: swap to show fallback text immediately:
@font-face {
font-family: 'CustomFont';
src: url('/font.woff2') format('woff2');
font-display: swap;
}
6. Use Content Placeholders
Show skeleton screens or placeholder content while the real content loads. This improves visual completeness even before data arrives.
Speed Index in Lighthouse Scoring
Speed Index accounts for 10% of your overall Lighthouse performance score. While it's not the heaviest-weighted metric (TBT is 30%, LCP is 25%), it contributes to the overall picture.
| Metric | Weight |
|---|---|
| TBT | 30% |
| LCP | 25% |
| CLS | 25% |
| FCP | 10% |
| Speed Index | 10% |
Measuring Speed Index
Speed Index requires visual analysis of the page loading process, so it can only be measured in lab environments:
- Lighthouse — built into Chrome DevTools and CI tools
- WebPageTest — provides filmstrip view alongside Speed Index
- BadPageSpeed — tracks Speed Index over time with automated Lighthouse audits
It's not available as a field metric because it requires capturing video frames.
Track Your Speed Index Over Time
A single Speed Index measurement is a snapshot. Track it continuously to catch regressions from new deployments, third-party script changes, or content updates.
Ready to stop wasting ad spend?
Track your landing page performance, monitor Core Web Vitals, and calculate exactly how much slow pages cost you.
Start Free — No Credit Card