Speed Index

TL;DR — Speed IndexStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. is a Lighthouse scoreLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. for how quickly the stuff on your page shows up while it loads. Lower (faster) is better, measured in seconds. On mobile, under 3.4 s is good. It’s not a Core Web Vital and it doesn’t directly affect your Google rankings — but the things that fix it usually help the metrics that do.

What Speed Index is

When you run a page through LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. or PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking., one of the numbers you get back is Speed IndexSpeed Index measures how quickly content is visually displayed during page load — the average time at which visible parts of the page appear, scored in seconds (lower is better). It's a lab-only Lighthouse metric, not a Core Web Vital and not a ranking factor.. It answers a simple question: how fast does the visible part of your page fill in?

Most speed metrics mark a single moment — like when the first bit of content appears (First Contentful PaintFirst Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital.) or when the biggest thing appears (Largest Contentful Paint). Speed Index is different. It watches the whole load and gives you an average of how quickly things became visible. A page that paints everything almost instantly gets a low (good) score; a page that sits blank and then dribbles content in gets a high (bad) one.

How to read your score

Lighthouse grades Speed Index on mobile like this:

• Good: 0 – 3.4 s (green)
• Needs improvement: 3.4 – 5.8 s (orange)
• Poor: more than 5.8 s (red)

Desktop is much stricter — good is roughly under 1.3 s — because Lighthouse tests mobile on a simulated slower device. So don’t compare a desktop number to a mobile one; they’re on different scales.

Does it matter for SEO?

Here’s the part people get wrong. Speed Index is not a Core Web Vital, and it is not a Google ranking factor. Google’s page-experience signals come from Core Web Vitals (LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good., INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good., and CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good.) measured on real users. Speed Index isn’t one of them and isn’t even measured on real users — it needs a video recording of the load, which only happens in testing tools.

That doesn’t make it useless. The fixes that improve Speed Index — a faster server, fewer render-blockingRender-blocking resources are CSS and synchronous JavaScript files a browser must download and process before it can paint any visible content. They sit on the critical rendering path and delay First Contentful Paint and Largest Contentful Paint. files, text that stays visible while fonts load — are the same fixes that improve FCPFirst Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital. and LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good.. So a better Speed Index usually travels alongside a better LCP, which does matter.

If you want the formula, the WebPageTestWebPageTest is a free, open-source, lab-based website performance testing tool — created by Patrick Meenan in 2008 and acquired by Catchpoint in 2020 — that runs pages on real browsers from distributed locations and produces deep diagnostics (waterfalls, filmstrips, connection views, Core Web Vitals). It's a diagnostic tool, not a Google ranking input. history, where it sits in the Lighthouse score, and the limitations to watch for, switch to the Advanced tab.

TL;DR — Speed IndexStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. measures how quickly content is visually displayed during page load — the average time visible content appears, scored in seconds (lower is better). It’s computed from a video of the load by summing the area above the visual-progress curve, which makes it a lab-only metric (not in CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program., PSIPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. field dataPerformance metrics captured from real users, not lab tests., or Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results.). It originated in WebPageTestWebPageTest is a free, open-source, lab-based website performance testing tool — created by Patrick Meenan in 2008 and acquired by Catchpoint in 2020 — that runs pages on real browsers from distributed locations and produces deep diagnostics (waterfalls, filmstrips, connection views, Core Web Vitals). It's a diagnostic tool, not a Google ranking input. (Pat Meenan); LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. computes it via the open-source Speedline module. It is not a Core Web Vital and not a ranking factor — it’s one of five LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. metrics, weighted 10% in Lighthouse 10. Mobile: Good ≤ 3.4 s, Needs improvement ≤ 5.8 s, Poor > 5.8 s; desktop good ≤ ~1.3 s. It can’t be faster than FCPFirst Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital., it’s viewport-dependent, and it improves with the same fixes as FCPFirst Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital./LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good..

What Speed Index actually measures

Google’s definition is one line: “Speed IndexSpeed Index measures how quickly content is visually displayed during page load — the average time at which visible parts of the page appear, scored in seconds (lower is better). It's a lab-only Lighthouse metric, not a Core Web Vital and not a ranking factor. measures how quickly content is visually displayed during page load.” The key word is visually. Speed Index isn’t a single timestamp the way First Contentful Paint and Largest Contentful Paint are — it’s a composite score that represents the average time at which the visible parts of the page are displayed. Lower is better, and it’s reported in seconds.

The mental model I find clearest: draw a graph with time on the X axis and “percent of the page visually complete” on the Y axis, climbing from 0% to 100%. Speed Index is the area above that curve. The faster the curve climbs to 100%, the smaller the area, the better the score. A page that’s blank for a while leaves a big rectangle of empty area above the line; a page that paints fast leaves almost none.

How it’s calculated

Lighthouse captures a video of the page loading and computes the visual progression between frames. Each interval of time gets weighted by how incomplete the page still is at that moment — a fully blank frame counts at 100%, a mostly-rendered frame counts for very little. The original WebPageTestWebPageTest is a free, open-source, lab-based website performance testing tool — created by Patrick Meenan in 2008 and acquired by Catchpoint in 2020 — that runs pages on real browsers from distributed locations and produces deep diagnostics (waterfalls, filmstrips, connection views, Core Web Vitals). It's a diagnostic tool, not a Google ranking input. formula is:

Speed Index = Σ ( interval × (1 − visual completeness% / 100) )

A worked example makes it concrete. DebugBear walks through one load like this:

• 0% complete (0–253 ms) → 253.0 ms contribution
• 43% complete (253–403 ms) → 85.5 ms contribution
• 98% complete (403–536 ms) → 2.7 ms contribution
• 99% complete (536–653 ms) → 1.2 ms contribution
• Total: 342.3 ms

Notice the first chunk: while nothing is visible, all of that time contributes at full weight. That’s why Speed Index can never be faster than First Contentful Paint — every millisecond before the first content paints is counted at 100%.

Lighthouse doesn’t roll its own implementation here. It runs the open-source Speedline module (originally from Paul Irish), which applies the same visual-progress-from-video methodology as WebPageTest, working off Chrome DevTools traces with screenshots enabled. Speedline can compute a standard Speed Index (histogram difference between the current and final frame) or a perceptual variant using SSIM; the standard one is what you normally see.

What’s a good score

Lighthouse 10 grades Speed Index against real-website data from the HTTP Archive, and the thresholds differ sharply by device because Lighthouse simulates a mid-tier mobile device with throttling by default:

If you’ve seen the old “under 1,000 ms is good” benchmark floating around, that’s legacy WebPageTest guidance for a specific era and connection profile — not the current Lighthouse mobile bar. Always know which tool and which device/network settings produced the number you’re looking at, because the same page scores differently in Lighthouse, WebPageTest, and GTmetrix.

Where it sits in the Lighthouse score

Speed Index is one of five metrics in the Lighthouse 10 Performance score, and it’s weighted 10% — tied with FCP for the lowest weight:

The practical takeaway: chasing Speed Index in isolation is low ROI. Total Blocking Time (30%) and LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good. and CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good. (25% each) move the overall score far more. Unless Speed Index is the thing specifically failing, you’ll usually get more by fixing LCP and TBTTotal Blocking Time — the sum of the blocking portion (time above 50 ms) of every long task between First Contentful Paint and Time to Interactive. It's a lab-recommended metric and the lab proxy for INP, not a Core Web Vital. — and Speed Index improves as a side effect anyway. In PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. you’ll find Speed Index in the lab (Lighthouse) section, not in the field-data section up top.

Is Speed Index a Core Web Vital or a ranking factor?

No on both counts, and the distinction matters when you’re explaining a report to a stakeholder.

• It’s not a Core Web Vital. The Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. are LCP, INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good., and CLS, measured on real users via CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program.. Speed Index isn’t in that set and doesn’t show up in Search ConsoleGoogle's free tool for monitoring crawling, indexing, and search performance.’s Core Web Vitals reportThe Google Search Console report (under Experience) that shows how your indexed URLs perform on the Core Web Vitals — LCP, INP, and CLS — using real-user field data from CrUX, grouped by device, status, and clusters of similar-performing URLs..
• It’s not a direct ranking factor. Google’s page-experience signal uses Core Web VitalsWeb Vitals is Google's initiative (launched May 2020) for unified page-experience quality signals. Core Web Vitals — LCP, INP, and CLS — are the subset used in ranking; the rest (TTFB, FCP, TBT, Speed Index) are diagnostic, not ranking factors. field data. Speed Index is a lab-only diagnostic that Google doesn’t collect from real users, so there’s no direct path from your Speed Index number to rankings.

The relationship to rankings is indirect: the problems that produce a bad Speed Index — slow TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good., render-blocking CSS/JS, invisible text during font swap — are the same ones that produce a bad FCP and LCP. Fix them and a better Speed Index usually tracks a better LCP, which is the part Google actually rewards.

Why it’s lab-only

Speed Index needs a frame-by-frame video of the page renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM., then image processing to compute visual completeness on each frame. That’s far too expensive to run on every real visitor, so it only exists in synthetic/lab tools — Lighthouse, WebPageTest, GTmetrix. Real User Monitoring and the CrUX dataset simply don’t carry it. If you need field performance data, you use Core Web Vitals; Speed Index is for diagnosing rendering in a controlled test.

Where it came from

Speed Index originated in WebPageTest, which Pat Meenan created and open-sourced in 2008 (the metric itself was added around 2012). It was designed to fix a real gap in the metrics of the time:

• Render start could fire on a single pixel or a background color — not meaningful content.
• Document complete (onload) includes below-the-fold and irrelevant resources.

Speed Index split the difference by measuring above-the-fold visual completeness over time — a better proxy for what a user actually perceives. Lighthouse later adopted that methodology through the Speedline module, which is why the WebPageTest and Lighthouse numbers share a lineage even though their throttling differs.

How to improve it

There’s no Speed Index-specific trick — Google’s own guidance is that anything you do to improve page load speed will improve your Speed Index score. In practice:

• Cut server response time (TTFB). Every millisecond before the first byte is blank-page time counted at full weight.
• Eliminate render-blocking CSS and JavaScript. These delay first paint, which is the most expensive part of the curve. Inline critical CSSCritical CSS is a performance technique that extracts the styles needed to render a chosen above-the-fold view, inlines them in the <head>, and defers the rest of the stylesheet. It speeds up first paint but is an advanced, optional optimization — Google says most sites don't need it — and carries real production risks around caching, CSP, and page state., defer the rest.
• Fix font loadingFont loading is how a browser fetches, applies, and renders custom web fonts — and specifically what it shows while the font file downloads. Those choices, controlled mainly by the CSS font-display property, directly affect two Core Web Vitals: LCP and CLS.. During a font swap, text can be invisible — counting as 0% complete for that span. font-display: swap (or optional) keeps text visible. This is one of the audits Lighthouse explicitly flags for Speed Index.
• Minimize main-thread work and reduce JavaScript execution time — the other two diagnostics Lighthouse calls out as high-impact for Speed Index.
• Prioritize above-the-fold content. Speed Index only cares about the visible viewport, so getting the first screen painted fast is the whole game.

These overlap almost completely with FCP and LCP optimization — which is exactly why I treat Speed Index as a corroborating signal, not a separate to-do list. Before you act on any single number, look at the load filmstrip (Lighthouse and WebPageTest both generate one) to confirm what’s actually painting early versus late, and compare a few repeated, like-for-like runs rather than one test — see the run-to-run variability note below.

Limitations worth knowing

• Lab-only — it never reflects a real user’s experience, only the test environment’s.
• Viewport-dependent — it measures the visible area, so mobile and desktop give very different results (hence the very different thresholds).
• SPA/AJAX blind spot — single-page apps can look artificially fast: the shell paints quickly while the real content loads later without a page refresh.
• Carousels, autoplay video, and consent overlays — anything that keeps changing pixels after the meaningful content has loaded can be penalized for continuing to register as “incomplete,” the same mechanism that penalizes auto-rotating carousels.
• Not a “fully loaded” metric — it measures above-the-fold visual progression, not when every script, image, or below-the-fold element finishes. WebPageTest’s separate Visually Complete metric (always ≥ Speed Index) is the one that catches a late lazy-loaded widget.
• Visual progress isn’t proof of usefulness. Speed Index only measures pixel change against a final frame — it doesn’t know whether what’s on screen is readable, correctly ordered, accessible, or actually interactive. A fast-painting skeleton or shell can score well while the real content (and the ability to use it) arrives later; that’s the same failure mode as the “meaningless early paint” anti-pattern above, just described from the metric’s side.
• Run-to-run variability. Because it’s derived from a single recorded load, Speed Index moves with the test conditions — Google’s own scoring guidance lists device differences, browser extensions, antivirus software, and even ad/A-B-test changes as sources of score fluctuation that have nothing to do with your code. Compare distributions from repeated, like-for-like runs, not one-off numbers.

Related metrics

Speed Index lives in the same web performance cluster as the Core Web Vitals hub and its neighbors. It’s closest to First Contentful Paint (Speed Index can’t beat FCP) and Largest Contentful Paint (same fixes, same root causes), sits alongside Total Blocking Time in the Lighthouse score, and you’ll meet it inside Lighthouse and PageSpeed Insights. For the field metrics that actually drive rankings, start at the Core Web Vitals hub.

AI summary

A condensed take on the Advanced version:

• Speed IndexStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. = how quickly content is visually displayed during load — a composite score (average time visible content appears), not a single timestamp. Reported in seconds; lower is better.
• Mental model: the area above the visual-progress curve (time vs. % visually complete). Computed from a video of the load, weighting each interval by how incomplete the page still is.
• Lab-only: needs frame-by-frame screenshots, so it’s not in CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program., PageSpeed Insights field dataPerformance metrics captured from real users, not lab tests., or Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results.. Use Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. for field data.
• Origin: WebPageTestWebPageTest is a free, open-source, lab-based website performance testing tool — created by Patrick Meenan in 2008 and acquired by Catchpoint in 2020 — that runs pages on real browsers from distributed locations and produces deep diagnostics (waterfalls, filmstrips, connection views, Core Web Vitals). It's a diagnostic tool, not a Google ranking input. (Pat Meenan, 2008; metric ~2012). LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. computes it via the open-source Speedline module — same methodology as WebPageTestWebPageTest is a free, open-source, lab-based website performance testing tool — created by Patrick Meenan in 2008 and acquired by Catchpoint in 2020 — that runs pages on real browsers from distributed locations and produces deep diagnostics (waterfalls, filmstrips, connection views, Core Web Vitals). It's a diagnostic tool, not a Google ranking input..
• Not a Core Web Vital, not a ranking factor. CWVs are LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good., INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good., CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good.. The link to rankings is indirect: fixing Speed IndexSpeed Index measures how quickly content is visually displayed during page load — the average time at which visible parts of the page appear, scored in seconds (lower is better). It's a lab-only Lighthouse metric, not a Core Web Vital and not a ranking factor. usually improves FCPFirst Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital./LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good..
• LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. 10 weight: 10% — tied with FCP for lowest. TBTTotal Blocking Time — the sum of the blocking portion (time above 50 ms) of every long task between First Contentful Paint and Time to Interactive. It's a lab-recommended metric and the lab proxy for INP, not a Core Web Vital. (30%) and LCP/CLS (25% each) matter far more, so chasing Speed Index alone is low ROI.
• Thresholds (mobile): Good ≤ 3.4 s, Needs improvement ≤ 5.8 s, Poor > 5.8 s; desktop good ≤ ~1.3 s. It can’t be faster than FCP and is viewport-dependent.
• Fixes = FCP/LCP fixes: faster TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good., fewer render-blocking resourcesRender-blocking resources are CSS and synchronous JavaScript files a browser must download and process before it can paint any visible content. They sit on the critical rendering path and delay First Contentful Paint and Largest Contentful Paint., font-display: swap, less main-thread/JS work, prioritize above-the-fold.
• Limitations: SPAs can score artificially well; carousels, autoplay video, and consent overlays can be penalized; it’s not a “fully loaded” measure; visual progress isn’t proof the content is readable, accessible, or usable; and a single run can be moved by device, extensions, or ad/A-B changes that have nothing to do with your code.

Official documentation

Primary-source documentation for Speed IndexStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed..

Google / LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal.

• Speed Index (Lighthouse audit) — the canonical reference: definition, how LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. computes it via Speedline, scoring thresholds, and the optimization audits.
• Lighthouse performance scoring — where the 10% Speed IndexSpeed Index measures how quickly content is visually displayed during page load — the average time at which visible parts of the page appear, scored in seconds (lower is better). It's a lab-only Lighthouse metric, not a Core Web Vital and not a ranking factor. weight and the full metric breakdown live.
• Minimize main-thread work — one of the three audits Lighthouse flags as high-impact for Speed Index.
• Reduce JavaScript execution time — the second flagged audit.
• Ensure text remains visible during webfont load (font-display) — the third flagged audit.

Origin / implementation

• Speedline (paulirish/speedline) — the open-source module Lighthouse uses to compute Speed Index from DevTools traces.
• Lighthouse source — speed-index.js — the audit’s description constant.
• WebPageTest — About — Pat Meenan created and open-sourced WebPageTestWebPageTest is a free, open-source, lab-based website performance testing tool — created by Patrick Meenan in 2008 and acquired by Catchpoint in 2020 — that runs pages on real browsers from distributed locations and produces deep diagnostics (waterfalls, filmstrips, connection views, Core Web Vitals). It's a diagnostic tool, not a Google ranking input., where Speed Index originated.

Quotes from the source

On-the-record statements. Each Google/LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. link is a deep link that jumps to the quoted passage.

Google — what Speed IndexStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. measures

• “Speed IndexSpeed Index measures how quickly content is visually displayed during page load — the average time at which visible parts of the page appear, scored in seconds (lower is better). It's a lab-only Lighthouse metric, not a Core Web Vital and not a ranking factor. measures how quickly content is visually displayed during page load.” — LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. Speed Index audit. Jump to quote

Google — how the score is set

• “Your Speed Index score is a comparison of your page’s speed index and the speed indexes of real websites, based on data from the HTTP Archive.” — Lighthouse Speed Index audit. Jump to quote

Relayed sources (paraphrased from secondary documentation, not quoted verbatim)

• Lighthouse captures a video of the page loading, computes the visual progression between frames, and generates the score with the Speedline module — based on the same principles as the original WebPageTestWebPageTest is a free, open-source, lab-based website performance testing tool — created by Patrick Meenan in 2008 and acquired by Catchpoint in 2020 — that runs pages on real browsers from distributed locations and produces deep diagnostics (waterfalls, filmstrips, connection views, Core Web Vitals). It's a diagnostic tool, not a Google ranking input. Speed Index. (Lighthouse Speed Index audit, computation section.)
• The longer a frame is visible and the less complete the page is at that point, the more that frame contributes to the score — and because all pre-FCPFirst Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital. time counts at 100%, Speed Index can’t be faster than First Contentful Paint. (DebugBear, Speed Index docs.)
• Speed Index is only available in synthetic/lab testing because of the cost of frame-by-frame screenshot processing. (DebugBear, Speed Index docs.)
• The metric was added to WebPageTestWebPageTest is a free, open-source, lab-based website performance testing tool — created by Patrick Meenan in 2008 and acquired by Catchpoint in 2020 — that runs pages on real browsers from distributed locations and produces deep diagnostics (waterfalls, filmstrips, connection views, Core Web Vitals). It's a diagnostic tool, not a Google ranking input. around 2012, on top of the tool Pat Meenan open-sourced in 2008. (KeyCDN; WebPageTest About page.)

Speed Index cheat sheet

Thresholds (LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. 10)

LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. 10 Performance weights

Fast facts

• Measures visual completeness over time (area above the progress curve), not a single timestamp. Lower is better.
• Lab-only — not in CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program., PSIPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. field dataPerformance metrics captured from real users, not lab tests., or Search ConsoleGoogle's free tool for monitoring crawling, indexing, and search performance..
• Not a Core Web Vital; not a direct ranking factor.
• Can never be faster than FCPFirst Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital. (pre-FCP time counts at 100%).
• Viewport-dependent — mobile and desktop scores differ a lot.
• Computed by Speedline; originated in WebPageTestWebPageTest is a free, open-source, lab-based website performance testing tool — created by Patrick Meenan in 2008 and acquired by Catchpoint in 2020 — that runs pages on real browsers from distributed locations and produces deep diagnostics (waterfalls, filmstrips, connection views, Core Web Vitals). It's a diagnostic tool, not a Google ranking input. (Pat Meenan).

Improve it (same as FCP/LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good.)

• Cut TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good. (faster server response).
• Remove render-blocking CSS/JS; inline critical CSSCritical CSS is a performance technique that extracts the styles needed to render a chosen above-the-fold view, inlines them in the <head>, and defers the rest of the stylesheet. It speeds up first paint but is an advanced, optional optimization — Google says most sites don't need it — and carries real production risks around caching, CSP, and page state..
• font-display: swap / optional so text stays visible.
• Minimize main-thread work and JS execution time.
• Prioritize above-the-fold renderingTurning HTML, CSS, and JavaScript into the final visual page and DOM..

Don’t be fooled

• “Under 1,000 ms” is old WebPageTest guidance, not the Lighthouse mobile bar.
• SPAs can score artificially well; carousels can be penalized.

Tools that report Speed Index

• LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. (in Chrome DevTools, the CLI, or the Node module) — reports Speed IndexStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. as one of the five Performance metrics, computed via Speedline.
• PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. — runs LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. and shows Speed IndexSpeed Index measures how quickly content is visually displayed during page load — the average time at which visible parts of the page appear, scored in seconds (lower is better). It's a lab-only Lighthouse metric, not a Core Web Vital and not a ranking factor. in the lab (Diagnostics) section. Note: the field-data section up top uses Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data., so Speed Index never appears there.
• WebPageTestWebPageTest is a free, open-source, lab-based website performance testing tool — created by Patrick Meenan in 2008 and acquired by Catchpoint in 2020 — that runs pages on real browsers from distributed locations and produces deep diagnostics (waterfalls, filmstrips, connection views, Core Web Vitals). It's a diagnostic tool, not a Google ranking input. — where the metric originated; reports Speed Index alongside Visually Complete and filmstrip views, with configurable connection profiles.
• GTmetrix — surfaces Speed Index in its UI, using WebPageTestWebPageTest is a free, open-source, lab-based website performance testing tool — created by Patrick Meenan in 2008 and acquired by Catchpoint in 2020 — that runs pages on real browsers from distributed locations and produces deep diagnostics (waterfalls, filmstrips, connection views, Core Web Vitals). It's a diagnostic tool, not a Google ranking input. data; its numbers won’t match Lighthouse’s because of different device/network simulation.
• DebugBear — synthetic monitoring with a clear frame-by-frame breakdown of how the Speed Index score was computed.

A reminder when comparing tools: the same page produces different Speed Index values across Lighthouse, WebPageTest, and GTmetrix because of their different throttling and device assumptions. Compare like with like.

Speed Index mistakes that waste optimization time

• Calling Speed IndexStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. a Core Web Vital. It is a lab-only visual-progress metric, not a field ranking signal. Use it to diagnose how a page fills in, then check the actual Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. separately.
• Comparing mobile and desktop thresholds. LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. uses different scoring curves and test conditions. Track one profile over time rather than treating the two scores as interchangeable.
• Improving the number with a meaningless early paint. A header shell can make visual progress start earlier while the primary content remains blank. Review the load filmstrip with the metric.
• Optimizing every image before checking the critical path. Slow TTFBTime to First Byte — the time from the start of a request to when the first byte of the response arrives. It's a diagnostic metric (not a Core Web Vital) and a major input to FCP and LCP; ≤0.8 s is good., render-blocking CSSRender-blocking resources are CSS and synchronous JavaScript files a browser must download and process before it can paint any visible content. They sit on the critical rendering path and delay First Contentful Paint and Largest Contentful Paint., fonts, and synchronous JavaScript can delay the whole visual sequence. Find the first bottleneck in the waterfall and trace.
• Expecting a stable single-run value. Speed IndexSpeed Index measures how quickly content is visually displayed during page load — the average time at which visible parts of the page appear, scored in seconds (lower is better). It's a lab-only Lighthouse metric, not a Core Web Vital and not a ranking factor. is derived from a synthetic video and moves with the test environment. Repeat comparable runs before declaring a regression or win.

Test yourself: Speed Index

Five quick questions on what Speed IndexStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. measures. Pick an answer for each, then check.

Resources worth your time

Official

• Speed Index — Lighthouse audit — the canonical definition, thresholds, and optimization audits.
• Lighthouse performance scoring — the metric weights, including Speed IndexStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed.’s 10%.
• WebPageTest — About — the origin of the metric.

Implementation

• paulirish/speedline — the open-source module LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. uses to compute Speed IndexSpeed Index measures how quickly content is visually displayed during page load — the average time at which visible parts of the page appear, scored in seconds (lower is better). It's a lab-only Lighthouse metric, not a Core Web Vital and not a ranking factor..

From others

• DebugBear — Speed Index — the clearest step-by-step worked example of the computation and the FCPFirst Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital. relationship.
• KeyCDN — Speed Index — historical context and the WebPageTestWebPageTest is a free, open-source, lab-based website performance testing tool — created by Patrick Meenan in 2008 and acquired by Catchpoint in 2020 — that runs pages on real browsers from distributed locations and produces deep diagnostics (waterfalls, filmstrips, connection views, Core Web Vitals). It's a diagnostic tool, not a Google ranking input. formula.
• Catchpoint — Speed Index — heir to the WebPageTestWebPageTest is a free, open-source, lab-based website performance testing tool — created by Patrick Meenan in 2008 and acquired by Catchpoint in 2020 — that runs pages on real browsers from distributed locations and produces deep diagnostics (waterfalls, filmstrips, connection views, Core Web Vitals). It's a diagnostic tool, not a Google ranking input. blog; visual-progress formula and the SPA/carousel limitations.
• Google Search Central — Core Web Vitals — confirms that LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good., INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good., and CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good. are the ranking signals; Speed Index is not listed, reinforcing that it has no direct ranking impact.
• web.dev — Vitals overview — the authoritative definition of Core Web VitalsGoogle's three real-user UX metrics — LCP (loading), INP (responsiveness), and CLS (visual stability) — used by Google's ranking systems, with no official weight attached, measured on field data. (LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good., INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good., CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good.); Speed Index is absent, useful when explaining why it doesn’t affect rankings.
• WebPageTest — Speed Index documentation — background on Pat Meenan’s creation of WebPageTest (open-sourced 2008) and where the Speed Index metric originated.

Numbers worth citing

• LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. weight: 10% of the Performance score in LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. 10 — tied with FCPFirst Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital. for the lowest weight, well behind TBTTotal Blocking Time — the sum of the blocking portion (time above 50 ms) of every long task between First Contentful Paint and Time to Interactive. It's a lab-recommended metric and the lab proxy for INP, not a Core Web Vital. (30%) and LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good./CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good. (25% each). Source
• Mobile “Good” ≤ 3.4 s; desktop “Good” ≤ 1.3 s — Lighthouse 10 thresholds, calibrated against HTTP Archive real-website data. Source
• Speed IndexStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. ≥ FCPFirst Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital., always — all time before first content paints contributes at 100%, so Speed IndexSpeed Index measures how quickly content is visually displayed during page load — the average time at which visible parts of the page appear, scored in seconds (lower is better). It's a lab-only Lighthouse metric, not a Core Web Vital and not a ranking factor. can’t come in faster than First Contentful Paint. Source
• Origin: WebPageTestWebPageTest is a free, open-source, lab-based website performance testing tool — created by Patrick Meenan in 2008 and acquired by Catchpoint in 2020 — that runs pages on real browsers from distributed locations and produces deep diagnostics (waterfalls, filmstrips, connection views, Core Web Vitals). It's a diagnostic tool, not a Google ranking input., ~2012 — added on top of the tool Pat Meenan open-sourced in 2008. Source

Speed Index

Speed Index measures how quickly content is visually displayed during page load — the average time at which visible parts of the page appear, scored in seconds (lower is better). It's a lab-only Lighthouse metric, not a Core Web Vital and not a ranking factor.

Related: Lighthouse, FCP, LCP

Speed Index

Speed IndexStoring a crawled page in the search index so it can appear in results. Crawled is not the same as indexed — Google selects what to keep, and indexing isn't guaranteed. (SI) measures how quickly content is visually displayed during page load. Rather than marking a single moment like First Contentful PaintFirst Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital. or Largest Contentful PaintLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good., it captures the average time at which the visible parts of the page appear — a composite score expressed in seconds, where lower is better.

It’s computed from a video of the page loading: a tool records the visual progression frame by frame, works out what percentage of the final page is visible at each point, and sums the “incompleteness” over time. A blank screen for a moment costs the full duration; a half-rendered screen costs half. Because it needs frame-by-frame screenshots, Speed Index is a lab-only metric — it can’t be collected from real users, so it doesn’t appear in CrUXChrome User Experience Report — Google's public dataset of real-world (field) performance data from eligible Chrome users. It's the official field-data source behind the Core Web Vitals program., PageSpeed InsightsPageSpeed Insights (PSI) is a free Google tool at pagespeed.web.dev that reports two kinds of data for a URL: real-user field data from the Chrome UX Report and a single Lighthouse lab run with the 0–100 Performance score. Only the field Core Web Vitals are what Google uses for ranking. field dataPerformance metrics captured from real users, not lab tests., or Search ConsoleA free Google service that reports how a site performs in Google Search and surfaces problems with how Google crawls, indexes, and serves it. It's first-party data straight from Google — but you don't need it to appear in results..

Speed Index originated in WebPageTestWebPageTest is a free, open-source, lab-based website performance testing tool — created by Patrick Meenan in 2008 and acquired by Catchpoint in 2020 — that runs pages on real browsers from distributed locations and produces deep diagnostics (waterfalls, filmstrips, connection views, Core Web Vitals). It's a diagnostic tool, not a Google ranking input. (created by Pat Meenan) and was later adopted by LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal., which computes it via the open-source Speedline module. In the LighthouseLighthouse is Google's free, open-source tool that audits a page under simulated lab conditions and scores it 0–100 across Performance, Accessibility, Best Practices, and SEO. It's lab data — useful for debugging, not a ranking signal. 10 Performance score it’s weighted 10% — tied with FCPFirst Contentful Paint — the time from when a page starts loading to when any part of its content (text, image, SVG, or non-white canvas) first renders. Good is ≤1.8 s at the 75th percentile. It's a diagnostic metric, not a Core Web Vital. as the lowest-weighted metric. It is not a Core Web Vital (those are LCPLargest Contentful Paint — render time of the largest visible image or text block, relative to when the page started loading. ≤2.5 s (at the 75th percentile) is good., INPInteraction to Next Paint — the input-to-paint latency at the 75th percentile of a page's interactions. ≤200 ms is good., and CLSCumulative Layout Shift — a unitless score for unexpected visual movement, taken from the largest burst (session window) of layout shifts, not the lifetime sum. ≤0.1 is good.) and not a direct Google ranking factor. It improves with the same fixes as FCP and LCP: faster server response and fewer render-blocking resourcesRender-blocking resources are CSS and synchronous JavaScript files a browser must download and process before it can paint any visible content. They sit on the critical rendering path and delay First Contentful Paint and Largest Contentful Paint..

Related: Lighthouse, FCP, LCP

Changelog