Is the speed index really Google's key metric for mobile performance?

What is the Speed Index Google is talking about?

The Speed Index measures how quickly visible content loads during a page's loading process. Unlike simple full load time, it captures the visual experience perceived by the user: a page may technically complete loading in 8 seconds, but if 90% of the visible content appears in 2 seconds, the Speed Index will be low (and thus good).

This metric has long been a staple of Lighthouse and PageSpeed Insights. It is calculated in milliseconds and represents the evolution of visual completeness in the viewport over time. A Speed Index of 3000 ms means that, on average, the visible content appears fully in 3 seconds.

Why does this statement raise questions today?

Since May 2021, Google has officially integrated Core Web Vitals as a mobile ranking factor: LCP (loading), FID/INP (interactivity), CLS (visual stability). The Speed Index has never been mentioned in this official communication about page experience signals.

Yet, this statement claims that Google primarily uses the Speed Index. The word is important: it suggests a prioritization, even exclusivity of this metric for assessing mobile speed. The threshold of 5000 ms indicated here is also much more lenient than the Core Web Vitals recommendations (LCP under 2500 ms to be considered 'good').

Where does this threshold of 5000 milliseconds come from?

The figure of 5000 ms does not correspond to any publicly documented standard in the Core Web Vitals guidelines. The official thresholds from Lighthouse classify the Speed Index as 'good' below 3400 ms, 'average' between 3400 and 5800 ms, and 'poor' beyond.

If Google actually sets an internal threshold at 5000 ms, it would imply a greater tolerance than what is displayed in its own public auditing tools. Either this statement predates the redesign of the metrics, or it reveals a gap between public discourse (CWV) and the actual criteria for mobile crawling/indexing.

• Speed Index: a visual perception metric that calculates the progressive completeness of the viewport
• 5000 ms threshold: more lenient than Lighthouse recommendations (3400 ms) and significantly higher than the optimal LCP (2500 ms)
• Apparent contradiction: no mention of the Speed Index in official communication about Core Web Vitals since 2021
• Practitioner implication: if this threshold is still applied, many sites ranked 'average' on LCP could technically pass Google’s threshold
• Probable dating: this statement strongly suggests the pre-CWV era, when the Speed Index was still Google's flagship metric for mobile

Is this statement still relevant in practice?

Let’s be honest: everything indicates that this statement is outdated. Since the official announcement of Core Web Vitals as a mobile ranking factor (Page Experience Update), Google has never repositioned the Speed Index as a main metric. The official tools (Search Console, PageSpeed Insights) only report LCP, INP, and CLS in experience reports.

Field tests confirm that sites improving their LCP without touching the Speed Index observe gains in mobile rankings. Conversely, a site with an excellent Speed Index but a catastrophic LCP sees no observable advantage. The market has made its decision: CWV are the current practical reality. [To be verified]: Could Google still use the Speed Index as a secondary signal in the background, without ever documenting it publicly?

Why would Google have said that at the time?

The Speed Index was the leading metric before the invention of Core Web Vitals. It better captured the real visual experience than just 'load time', especially on mobile where progressive rendering matters a lot. An e-commerce site that displays products in 2 seconds but finishes loading after 8 seconds offers better UX than a site that displays everything at once at the 5-second mark.

The threshold of 5000 ms was likely a pragmatic compromise between the ideal (ultra-fast sites) and the reality of global mobile web (slow connections, heavy JS, unoptimized images). Google has always aimed not to massively penalize sites making reasonable efforts.

Which metric should you really monitor today?

The answer is unequivocal: focus on Core Web Vitals. LCP (Largest Contentful Paint) measures the loading of the largest visible element, INP (Interaction to Next Paint) replaces FID to assess responsiveness, and CLS (Cumulative Layout Shift) penalizes unexpected visual shifts.

The Speed Index remains a useful complementary metric for diagnosing progressive rendering issues, but it is no longer a documented ranking factor. If you need to prioritize your optimizations, aim for an LCP below 2500 ms and an INP below 200 ms. The Speed Index will naturally follow if you optimize the critical rendering path correctly.

What to do if your Speed Index exceeds 5000 ms?

Even if this metric is probably no longer the main criterion, a high Speed Index often indicates structural performance issues that also impact your Core Web Vitals. A Speed Index above 5000 ms generally indicates blocked rendering, heavy JavaScript executing too early, or non-prioritized critical resources.

Specifically, audit your critical rendering path: identify blocking CSS and JS, defer what is not necessary above the fold, and ensure that the main content loads first. The same optimizations that lower the Speed Index will mechanically improve your LCP.

How to prioritize between Speed Index and Core Web Vitals?

This question should not even arise: prioritize Core Web Vitals. It is the only officially documented page experience signal measured in Search Console. If you are still working with clients or tools that emphasize the Speed Index as a main metric, realign the conversation.

That said, if you optimize correctly for LCP, you will de facto improve your Speed Index. The two metrics share many common levers: image compression, smart lazy loading, elimination of render-blocking resources, prioritization of critical resources. The difference is that LCP is simpler to measure and explain to a non-technical client.

What mistakes to avoid when interpreting this statement?

Do not fall into the trap of believing that a threshold of 5000 ms gives you leeway to ease your efforts. Google has since significantly tightened its requirements with Core Web Vitals. A site that merely grazes the 5000 ms Speed Index will likely have a catastrophic LCP (beyond 4 seconds), putting it in the red zone.

Another classic mistake: optimizing for PageSpeed Insights without checking field data (CrUX). The Speed Index is measured in lab settings on Lighthouse, but Google ranks your site based on real user experiences collected via the Chrome User Experience Report. A site may score 90/100 in the lab and be penalized if 75% of its real visitors experience an LCP longer than 4 seconds.

• Audit your Core Web Vitals in Search Console (real field data)
• Aim for an LCP below 2500 ms and an INP below 200 ms as an absolute priority
• Use the Speed Index as a complementary diagnostic metric, not as the main goal
• Optimize the critical rendering path: defer non-critical JS/CSS, compress images, use a CDN
• Test on actual mobile connections (3G/4G), not just on WiFi or fiber optics
• Monitor regressions after each deployment with continuous monitoring (WebPageTest, SpeedCurve, Lighthouse CI)