You open a supplier's website: the logo shows up quickly, but the services block stays empty for another two seconds. That uneven visual load is what Speed Index captures—how fast visible content fills the viewport during loading. In 2026 it remains one of the most practical lab metrics for business sites where first impression matters before anyone reads a line of copy.
This article explains what Speed Index measures, Lighthouse thresholds, how it relates to FCP, LCP, and TBT, and which changes usually make the page feel "fully there" sooner without gutting your design.
What Speed Index is and what it measures
Speed Index is a lab metric (Lighthouse, WebPageTest). It scores how quickly visible content is painted in the viewport using loading filmstrip frames. A low score means the page becomes visually useful fast; a high score points to long blank screens, endless placeholders, or late-arriving sections.
- Unlike LCP, it summarizes overall visual progress—not a single element.
- It penalizes pages that show little early even when final LCP looks fine.
- It complements FCP: first paint vs. how the rest catches up.
- PageSpeed reports it in seconds—lower is better.
See web.dev on Speed Index for the calculation and its role in performance audits.
Thresholds to use in 2026
Lighthouse still uses these mobile-simulated references:
- Good: 3.4 s or less.
- Needs improvement: 3.4 s to 5.8 s.
- Poor: above 5.8 s.
Desktop numbers are often lower, but prioritize campaign landing pages, home, services, and contact. A red Speed Index on mobile often correlates with bounce before scroll.
Speed Index vs. FCP, LCP, and TBT
Core Web Vitals in the field measure real users; Speed Index diagnoses how loading feels in the lab. You can have acceptable LCP if a hero image appears late while the rest of the layout stays empty—Speed Index catches that gap.
Fast FCP with high Speed Index feels like "something showed up, but the page never finishes." High TBT can delay paint for hydrated components and push the index up.
Common causes on business websites
- Heavy hero without load priority or responsive sizing.
- Web fonts blocking visible text or causing late repaints.
- Missing critical CSS or huge bundles before first render.
- JavaScript hiding content until execution (unnecessary spinners).
- Below-the-fold images competing with above-the-fold bytes.
- Autoplay sliders and video delaying the rest of the layout.
Image optimization and well-implemented lazy loading are often the fastest levers when the filmstrip shows long gaps.
How to measure Speed Index
- PageSpeed Insights / Lighthouse: "Speed Index" in the performance report.
- WebPageTest: filmstrip plus Speed Index by connection and device.
- Chrome DevTools → Lighthouse: repeatable locally with mobile throttling.
- Before/after comparisons on the same URL after each release.
Always log URL, date, and template. Shaving 0.8 s on the homepage may not move LCP but can improve Speed Index if middle content appears sooner.
Actions that usually improve Speed Index
Prioritize what users see first
Mark hero and logo with fetchpriority="high", serve modern formats (WebP or AVIF), and set width/height to avoid layout shift. Defer sliders and maps until needed.
CSS and first render
Cut render-blocking CSS on the critical path: inline above-the-fold styles, drop unused rules on the homepage, avoid chained @import. Minification helps, but what paints first matters more for the index.
Fonts and visible text
Use font-display: swap, character subsets, and preload only the weight used in the hero. Readable text early improves the filmstrip even while images still download.
Less blocking on initial load
Defer non-essential scripts and reduce long tasks that block sections from painting. Avoid hiding all content until React or Vue finish hydrating when static HTML can be visible.
Server and network
High TTFB delays every paint. Combine caching, a CDN, and compression so HTML and critical CSS arrive sooner.
Mistakes that keep Speed Index high
- Tuning only LCP while ignoring gaps in the middle of the filmstrip.
- Full-screen branded loaders for three seconds.
- Loading every image on the page with high priority.
- Confusing Speed Index with total load time or INP.
- Measuring desktop only when most traffic is mobile.
Quick checklist before your next release
- Run mobile Lighthouse on home and contact; note Speed Index, FCP, and LCP.
- Review the filmstrip: how many seconds stay under 50% viewport painted?
- Prioritize hero, typography, and critical CSS; defer the rest.
- Re-test after deploy and compare screenshots.
Conclusion
Speed Index does not replace field Core Web Vitals, but it explains why a site feels slow when a single metric looks green. On business websites, where trust is won in the first seconds, track it alongside FCP and LCP. If you need a prioritized audit of critical templates, aatsoft can help turn reports into concrete changes without breaking marketing or design.
