Speed Index
Speed Index measures how quickly the visible part of a page fills in during load. Lighthouse records a video of the page loading, compares each frame with the final, fully loaded screen, and calculates how visually complete the viewport was over time. The result is expressed in seconds: a lower Speed Index means most of the content appeared early.
Two pages can have the same First Contentful Paint and Largest Contentful Paint and still feel different. One shows most of its content right away; the other shows a logo, then waits, then paints everything at the end. Speed Index captures that difference.
Why it matters
Visitors judge speed by what they see. A page that renders progressively feels faster than one that stays mostly empty and then appears all at once, even if both finish at the same moment. Speed Index also counts toward the Lighthouse performance score, with a smaller weight than the Core Web Vitals.
What we check
We read the Speed Index value from the Lighthouse mobile run in PageSpeed Insights:
| Result | Speed Index |
|---|---|
| Good | 3.4 s or less |
| Needs attention | over 3.4 s, up to 5.8 s |
| Poor | over 5.8 s |
Speed Index is a lab-only metric. It has no real-user counterpart in the Chrome UX Report.
What slows it down
Speed Index rises when the first screen stays incomplete for a long time. Typical causes:
- Render-blocking CSS and JavaScript that delay the first paint.
- Content rendered by JavaScript after a large bundle runs, instead of being in the HTML.
- Large, late-loading images above the fold.
- Web fonts that keep text invisible while they download.
- Busy main thread: long JavaScript tasks during load delay rendering updates.
- Loading screens, spinners or fade-in animations that hide content that is already available.
How to fix
Most fixes overlap with the ones for FCP and LCP. Focus on what is visible on the first screen:
Put above-the-fold content in the HTML. Server-side rendering or static generation lets the browser paint text and layout as soon as the HTML arrives.
Inline critical CSS and defer scripts. Keep the first-screen styles small and in the <head>,
and add defer to scripts so they do not block parsing:
<script src="/app.js" defer></script>
Load first-screen images early and everything else late. Do not lazy-load images in the first viewport. Do lazy-load images further down the page, so they do not compete for bandwidth:
<img src="/gallery-3.webp" width="600" height="400" loading="lazy" alt="..." />
Show text immediately. Use font-display: swap in your @font-face rules so text renders in a
fallback font while the web font loads.
Remove artificial delays. Fade-in-on-load effects, page-level spinners and “reveal” animations
that start with content hidden (for example opacity: 0) all push Speed Index up. If you keep an
animation, make sure the content is visible from the first frame.
Reduce main-thread work during load. See the Total Blocking Time guide for ways to cut and defer JavaScript.