What Is Speed Index? Complete Guide (2026)

Saar TwitoPublished May 21, 2025Updated April 30, 20268 min read

Saar TwitoFounder & SEO Engineer

Hi, I'm Saar - a software engineer, SEO specialist, and lecturer who loves building tools and teaching tech.

What Is Speed Index?

Speed Index is a lab-data performance metric that measures how quickly the visible portion of a page becomes complete during load. It is not the moment the first pixel paints (FCP) or the moment the largest element renders (LCP) — it is a weighted average of how filled-in the viewport looks across every frame of the loading process. Lower is better.

Key Facts (TL;DR)

Good Speed Index: ≤ 3.4 seconds — visible content fills in quickly and consistently.
Needs Improvement: 3.4 – 5.8 seconds — visitors notice the page filling in piece by piece.
Poor: > 5.8 seconds — page feels half-loaded for an uncomfortable stretch; bounce risk climbs sharply.
Performance score weight: Speed Index contributes approximately 10% of your overall web performance score.
Lab metric only: Speed Index is calculated by sampling video frames during a synthetic test, frame by frame. It is not measured for real users (no equivalent CrUX field metric).
Frame-by-frame visual analysis — adopted as a core lab metric across the industry because it correlates better with perceived speed than any single point-in-time measurement.
Business impact: Cross-industry research shows perceived loading speed has a non-linear effect on bounce rate — a page that feels half-loaded for 4+ seconds loses ~32% of mobile visitors before any interaction (Google mobile speed research).

Think of Speed Index the way you think of pouring water into a glass. FCP is when the first drop hits. LCP is when the biggest stream lands. Speed Index is the average fullness of the glass over time — it rewards pages that fill steadily and quickly, and punishes pages that pour for a second, pause, and dump the rest at the end.

Why Speed Index Matters for Engagement and Rankings

Closest single proxy for perceived speed.Users don't experience a load as a sequence of metrics — they experience it as a film. Speed Index averages every frame, so it captures the visual story closer to how a human watches it.
Highlights wasted middle-of-load time.A page can have a fast FCP and a fast LCP and still have a poor Speed Index if there's a long blank stretch between them. That stretch is exactly what triggers abandonment.
Performance score weight: Speed Index carries ~10% of the total weight in standard performance audits — modest individually, but improving it almost always coincides with improvements to LCP and FCP, multiplying the score gain.
Indirect ranking impact:Speed Index itself isn't a Google ranking signal. But the same root causes (render-blocking CSS, slow images, slow TTFB) drag LCP and FCP — both of which feed the Page Experience signal directly.
AI search visibility: AI-driven search systems source citations preferentially from pages already ranking well. Anything that improves perceived load (Speed Index, FCP, LCP) compounds into better AI visibility too.

How Speed Index Is Calculated

Speed Index is computed from a video of the page loading. Each frame is scored for "visual completeness" — what percentage of the final viewport pixels are already in their final state. Then those scores are integrated over time.

Step 1 — Capture: The audit tool records video of the page load, frame by frame (typically at ~10 fps).
Step 2 — Score each frame:Each frame gets a "visual completeness" percentage (0% blank → 100% identical to final). Pixel-difference algorithms compute this against the final stable frame.
Step 3 — Integrate: Speed Index = the area above the visual-completeness curve, in milliseconds. A page that hits 100% completeness instantly would have a Speed Index of 0; a page that takes 4 seconds linearly would have ~2,000 ms.

Visual completeness over time:
   100% |                ___________________
        |               /
    50% |        ______/
        |       /
     0% |______/
        +------|------|------|------|------|→ time
        0s    1s     2s     3s     4s     5s

Speed Index ≈ shaded area above the curve (lower = better)

Why Speed Index Catches What FCP and LCP Miss

FCP fires the instant any content paints. LCP fires when the largest element finishes. Both are point-in-time measurements. Speed Index, by contrast, penalizes every second the viewport is incomplete — so it surfaces the awkward middle of a load (slow background fonts, late-arriving cards, progressive image enhancement) that single-moment metrics ignore.

How to Check Your Speed Index Score

Greadme's deep scan — surfaces Speed Index alongside every other Web Vital and pairs each issue with an AI-generated fix or one-click GitHub PR. Recommended starting point.
Greadme's crawler scan — measures Speed Index across every indexable page so you can spot which templates have the slowest visual fill (typically: heavy product pages, image-heavy article pages).
Chrome DevTools → Performance tab — record a load locally; the "Frames" lane shows the visual progression frame by frame, exposing exactly which milliseconds are wasted.
Google Search Console → Core Web Vitals report — Speed Index itself isn't reported there (no field equivalent), but slow LCP issues here are a strong proxy for which URLs likely have poor Speed Index too.
web.dev articles — Google's reference docs on visual progress, critical rendering path, and image optimization are the primary sources for the techniques in this guide.

8 Proven Ways to Improve Speed Index

1. Inline Critical CSS

Speed Index is dominated by what fills the viewport in the first 2–3 seconds. The single biggest win is removing the round-trip wait for external CSS by inlining the styles needed for above-the-fold content directly in <head>.

<head>
  <style>/* Critical above-the-fold CSS, ~10–14 KB max */</style>
  <link rel="preload" href="/styles/main.css" as="style"
        onload="this.onload=null;this.rel='stylesheet'">
</head>

2. Preload the Hero Image

The hero image (or hero video poster) usually dominates the visible area. Every millisecond of delay is multiplied across the integration. Preloading lets the browser fetch it before the parser would otherwise discover it.

<link rel="preload" as="image" href="/hero.webp"
      fetchpriority="high">

3. Compress and Modernize Images

Convert above-the-fold images to WebP or AVIF — typically 25–50% smaller than equivalent JPEGs at the same visual quality. Combined with proper width / heightattributes (so layout doesn't shift mid-load), this is the highest-leverage Speed Index improvement on most marketing pages.

4. Lazy-Load Below-the-Fold Media

Content the user can't see contributes nothing to Speed Index — but downloading it competes for bandwidth with the content that does. Defer it.

<img src="/below-the-fold.webp" loading="lazy"
     width="800" height="400" alt="...">

5. Defer or Async Non-Critical JavaScript

Render-blocking scripts pause the parser, freezing visual progress. Every blocking <script> in the head should be challenged.

Fix: Add defer or async to anything that doesn't need to run before paint. For inline scripts, move them to the end of <body>.

6. Use a CDN with Edge Caching

Speed Index starts the moment the browser first sees content. If your HTML is served from a single origin halfway across the world, the first 200–400 ms of every load is wasted on transit. Edge-cached HTML and assets can drop that to under 50 ms for most users.

7. Use `font-display: swap` for Web Fonts

The default font-loading behavior hides text for up to 3 seconds while a custom font downloads — every one of those frames is "visually incomplete" for Speed Index purposes. font-display: swap paints text immediately in a fallback, then swaps when the custom font arrives.

Bonus: Pair with size-adjust, ascent-override, and descent-override on a fallback @font-face declaration to minimize the visual jump when the swap happens.

8. Simplify Above-the-Fold Design

The most reliable way to improve Speed Index is to render less above the fold. A 3-MB autoplaying hero video, a complex slider, and four parallax sections may all be technically optimized — and still produce a slow Speed Index because they have so much pixel area to fill.

Fix: Audit your above-the-fold UI honestly. Often a single static hero image with one CTA outperforms a feature-packed alternative, both in Speed Index and conversion.

Speed Index vs Other Performance Metrics

Metric	What It Measures	Good Threshold	Difference From Speed Index
First Contentful Paint (FCP)	When any content first paints	≤ 1.8 s	Single moment vs. integrated visual progress
Largest Contentful Paint (LCP)	When the largest visible element finishes painting	≤ 2.5 s	Focuses on one element vs. full-viewport completeness
Time to Interactive (TTI)	When the main thread quiets enough to handle input	≤ 3.8 s	Measures interactivity vs. visual progress
Total Blocking Time (TBT)	How long the main thread is blocked during load	≤ 200 ms	Measures responsiveness vs. visual fill rate
Cumulative Layout Shift (CLS)	Unexpected layout movement	≤ 0.1	Measures stability vs. fill rate

Speed Index is the onlystandard performance metric that integrates over time rather than measuring a single moment. That's its strength — and why it sometimes uncovers problems the other metrics miss.

Common Speed Index Problems and Fixes

Problem: Slow Hero Image

What's happening: The hero is large, uncompressed, and loaded at default priority — so it arrives 2+ seconds into the load even though it dominates the viewport.

Fix: Convert to WebP/AVIF, add fetchpriority="high", preload it in <head>, and serve responsive sizes via srcset.

Problem: Render-Blocking CSS

What's happening: Multiple external stylesheets in <head> each add a round-trip before any paint — Speed Index pays for every one.

Fix: Inline the critical 10–14 KB and async-load the rest.

Problem: Late-Loading Async Sections

What's happening: The hero paints fast, but a related-products carousel, recommended-articles row, or chat widget loads 3 seconds in — and these sit above the fold.

Fix: Server-render anything above the fold. Reserve client-side rendering for genuinely interactive widgets that can wait.

Problem: Web Font "Flash of Invisible Text"

What's happening: Every text block hides for 1–3 seconds while a custom font loads. Each frame counts as "incomplete" for Speed Index.

Fix: Add font-display: swap to @font-face rules and tune fallback metrics with size-adjust.

FAQ

What is a good Speed Index score?

A good Speed Index is 3.4 seconds or less. Between 3.4 and 5.8 seconds "needs improvement," and over 5.8 seconds is poor. These thresholds apply to mobile lab tests; desktop expectations are typically 1–2 seconds tighter.

Is Speed Index a Core Web Vital?

No. The three Core Web Vitals are LCP (loading), INP (interactivity), and CLS (visual stability). Speed Index is a labmetric — it's computed from synthetic-test video frames, not real-user data. Google uses Core Web Vitals as ranking signals; Speed Index is informational and contributes to the lab performance score.

How is Speed Index different from Largest Contentful Paint?

LCP captures one moment: when the largest visible element finishes painting. Speed Index captures the entire shape of the load: how quickly the viewport fills in, integrated over every frame. A page can have a fast LCP and a slow Speed Index if smaller elements arrive sluggishly, or a slow LCP and an okay Speed Index if everything else paints fast and only the hero is late.

Why is there no field-data version of Speed Index?

Speed Index requires recording and analyzing video of the load, which is too expensive and privacy-invasive to do in real users' browsers at scale. Field metrics like LCP and INP can be derived from inexpensive browser APIs that are safe to expose; Speed Index cannot.

Why does Speed Index correlate so strongly with perceived speed?

Because users don't experience load as a single moment — they experience it as a movie. Point-in-time metrics (FCP, LCP) miss the awkward middle, where the page is half-painted and the user starts looking for the back button. Speed Index integrates that entire window, so it tracks user perception more closely than any single-moment metric.

Does Speed Index affect SEO?

Indirectly. Speed Index itself isn't a Google ranking signal. But the optimizations that improve Speed Index (fast hero images, inlined critical CSS, deferred JS) almost always also improve LCP, FCP, and CLS — and those are ranking signals.

Does Speed Index affect AI search engines like ChatGPT and Perplexity?

Indirectly, the same way it affects classic SEO. AI search systems preferentially cite pages already ranking well in Google. Anything that improves Speed Index typically lifts Core Web Vitals too, which improves rankings, which improves AI citation odds.

Conclusion

Speed Index is the single best metric for capturing how a load feels. It rewards pages that fill in steadily and punishes pages with awkward gaps, even when their headline metrics (FCP, LCP) look fine. It carries about 10% of the performance score on its own — but the optimizations that improve it (inlined critical CSS, preloaded hero image, modern image formats, deferred JS, font-display: swap) cascade into LCP, FCP, and CLS gains too.

Run a Greadme deep scan to see your Speed Index, identify which above-the-fold resources are slowing the visual fill, and get a prioritized fix list.