What Is Speed Index?

A testing tool records the page as it loads, compares each frame with the visually complete state and calculates how much of the viewport has reached its final appearance over time. Early progress lowers the score; long periods of blank or partially complete content increase it. Speed Index is reported as a time-like value, but it summarizes the full visual loading curve rather than marking one event. The result depends on the viewport, test hardware, network, browser, page content and visual-comparison method. It is a useful lab diagnostic, not a field Core Web Vital or a direct search-ranking verdict.

• Measured in a controlled page-load video
• Evaluates visual progress frame by frame
• Focuses the visible viewport
• Rewards early sustained content display
• Depends on the final visual reference frame
• Changes with device and test conditions

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

Primary specification: Chrome Lighthouse Speed Index documentation.

Speed Index is most useful when the visual progress curve is connected to the resources and rendering work responsible for incomplete frames.

The mobile and desktop ranges differ because device and audit profiles differ. Treat them as tool-specific score guidance rather than universal field thresholds. Lighthouse desktop marks 0–1.3 seconds as fast, 1.3–2.3 seconds as moderate and above 2.3 seconds as slow in its documented profile. Keep tool and version consistent before comparing releases. One score can also hide different visual paths: a page that jumps from blank to complete may match the total of a page that displays stable useful content progressively. Inspect filmstrips and progress curves alongside the number. Validate later content, stability and interaction rather than chasing color alone.

• Mobile fast: 0–3.4 seconds
• Mobile moderate: 3.4–5.8 seconds
• Mobile slow: above 5.8 seconds
• Desktop fast: 0–1.3 seconds
• Desktop moderate: 1.3–2.3 seconds
• Desktop slow: above 2.3 seconds

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

Use Speed Index ranges only inside a stable testing contract and let visual evidence determine whether the page’s progress is genuinely useful.

The exact implementation depends on the testing tool, image-comparison technique and capture pipeline. Conceptually, the initial frame begins near zero completeness and the reference final frame represents completion. Intermediate frames are compared with that final state. A page that reaches 60 percent visual completeness early earns a better score than one that remains blank and catches up later, even if both finish at the same moment. Animations, carousels, video and continuously changing regions can complicate the reference frame. Tools may mask or handle those areas differently. Preserve the filmstrip, visual-progress chart and audit version when reporting results.

1. Record the viewport throughout page load.
2. Select a visually complete reference state.
3. Compare each frame with that state.
4. Estimate visual completeness over time.
5. Integrate the remaining incompleteness.
6. Report the resulting time-like score.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

Speed Index calculation summarizes an entire visual sequence, so the sequence should always accompany the reported score.

These metrics can move independently. A page may show a small heading quickly for good FCP while most of the viewport stays blank, producing weaker Speed Index. A hero can produce good LCP while several visible cards continue appearing. High TBT may delay visual updates, but some long tasks occur after the view is complete. Speed Index does not measure interaction or layout stability. Use the set to describe response, first content, visual completion, main content, blocking and stability rather than collapsing them into one performance label.

• FCP: first content appears
• Speed Index: viewport fills over time
• LCP: largest candidate renders
• TBT: long-task blocking accumulates
• CLS: unexpected movement occurs
• INP: real interactions respond

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

Speed Index adds the shape of visual progress to a metric set, but it should never replace content, stability or responsiveness evidence.

Anything that keeps a large visible region different from its final state increases the score. A slow document response delays all progress. One blocking stylesheet can hold back most text and layout. A font policy may keep headings invisible. Images referenced through late CSS or JavaScript begin after the browser could have discovered them. A client application may show skeletons until data and bundles finish. Large overlays or consent components can dominate the visual comparison. Animations and rotating carousels create unstable reference frames. Diagnose which regions remain incomplete and trace their resource or execution dependencies.

• Slow response or redirect path
• Blocking CSS and font dependencies
• Primary media discovered late
• JavaScript application shell
• Large skeletons waiting for API data
• Main-thread tasks delaying paint
• Animated or changing viewport regions

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

A slow Speed Index should be reduced by fixing the resource or task that keeps the largest useful viewport region incomplete.

Prioritize the actual initial view. Load the hero or primary product image early, but keep secondary below-fold media under lazy loading. Use responsive image sources so mobile visitors do not transfer desktop-sized files. Deliver route-critical CSS through a short rendering path while avoiding duplicate frameworks. Provide readable fallback typography and load only required font weights. Reserve media dimensions so faster visual progress does not create layout shifts. A placeholder helps perceived progress only when it represents stable useful structure rather than delaying real content indefinitely.

1. Identify visible assets in each responsive viewport.
2. Expose primary media in initial HTML.
3. Serve correctly sized image candidates.
4. Deliver only route-critical styles early.
5. Use stable readable fallback fonts.
6. Reserve final media and component geometry.
7. Defer off-screen and optional visuals.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

Visual-resource optimization should fill the initial viewport sooner while preserving image quality, typography, layout stability and content meaning.

Start with the filmstrip rather than a generic checklist. Identify the largest incomplete region during the longest visual stall. If the page remains blank, fix TTFB and blocking delivery. If skeletons dominate, shorten API and client-rendering chains or deliver stable content on the server. If images lag, repair discovery, priority and responsive sizing. If progress pauses while scripts run, reduce long tasks. Avoid inserting meaningless early paint solely to improve the curve. Test the same route content, viewport and tool profile before and after each change.

1. Find the largest visual stall in the filmstrip.
2. Trace the incomplete region to its dependency.
3. Reduce response and redirect delay.
4. Deliver useful HTML and critical styles early.
5. Prioritize visible images and text.
6. Reduce early main-thread blocking.
7. Protect layout and interaction quality.
8. Repeat under the same lab contract.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

The strongest Speed Index improvement replaces incomplete frames with useful stable content rather than merely changing the visual-comparison algorithm’s inputs.

Select representative route families and realistic content. Keep viewport, device, CPU, network, cache and tool version stable. Run several times and review median and variance. Mark FCP, LCP, visual-completion milestones and long tasks. Identify animated regions that may distort comparison. Segment the screen into major content areas and note when each reaches its final state. Trace slow regions through waterfall initiators, CSS, fonts, APIs and execution. Apply one fix class at a time, regression-test layout and controls, and retain before-and-after filmstrips. Field metrics remain necessary because Speed Index itself is a laboratory visual metric.

1. Define a stable test profile.
2. Select representative route content.
3. Capture repeated videos and progress curves.
4. Identify the largest incomplete region.
5. Trace its network and execution path.
6. Account for animations and rotating content.
7. Verify content, layout and controls.
8. Compare the same profile after release.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

A complete Speed Index audit explains the visual loading curve through concrete resources and tasks, then proves a stable improvement under identical conditions.