Are Speed Index and First Meaningful Paint the mobile metrics that Google really recommends?

Why does Google differentiate between actual speed and perceived speed?

Perceived speed measures what a user sees during loading, not when the last line of code executes. A site can technically load in 2 seconds but appear ready in 800ms if the visible content displays quickly.

Speed Index calculates the visual progress of loading in the viewport. The faster the screen fills with useful content, the better the score. First Meaningful Paint identifies when the main content appears on the screen, the content that gives meaning to the page.

Are these metrics still relevant?

This recommendation dates back to a time when Core Web Vitals did not exist. Today, LCP (Largest Contentful Paint) has replaced First Meaningful Paint in official priorities. Speed Index remains available in Lighthouse but is no longer a ranking signal.

The paradox? Google continues to suggest these metrics in some documentation without specifying that they no longer directly serve ranking purposes. Official tools have evolved, but communication has not always followed suit.

How can these indicators be measured effectively?

Lighthouse (integrated into Chrome DevTools) automatically calculates Speed Index and displayed First Meaningful Paint until recently. WebPageTest offers a particularly revealing filmstrip visualization of Speed Index, showing the loading progress image by image.

For a mobile audit, launch Lighthouse in mobile throttling mode (simulated 4G connection). A good Speed Index is under 3.4 seconds on mobile, excellent under 1.3 seconds. Beyond 5.8 seconds, the experience is considered poor.

• Speed Index: overall visual loading progression, composite score in milliseconds
• First Meaningful Paint: moment when the main content becomes visible (now replaced by LCP)
• Perceived vs Technical Speed: prioritize the quick display of above-the-fold content even if secondary resources are still loading
• Recommended Tools: Lighthouse for quick audits, WebPageTest for detailed analyses with filmstrip
• Speed Index Thresholds: < 1.3s excellent, 1.3-3.4s average, > 5.8s poor

Is this recommendation still relevant for ranking?

Let's be honest: First Meaningful Paint has been deprecated by Google itself in favor of LCP. The official recommendation has clearly not been updated. FMP was difficult to calculate consistently across different page architectures.

Speed Index remains a relevant UX indicator but is not a direct ranking factor. Core Web Vitals (LCP, FID/INP, CLS) have taken over for the ranking algorithm. Continuing to optimize only Speed Index without monitoring LCP is counterproductive.

What inconsistencies are observed in the field?

Some sites display excellent Speed Index but have catastrophic LCP because they load secondary elements (header, navigation) before the main content. The opposite exists as well: quick LCP thanks to an optimized hero image, but a poor Speed Index because the rest of the page loads slowly.

[To be checked] The exact weighting of these metrics in the real user experience. Google claims to measure perceived speed, but the ranking criteria clearly favor LCP. The gap between official documentation and algorithmic practice creates confusion.

In what cases are these metrics still useful?

For pure UX diagnosis, Speed Index reveals issues that are invisible in Core Web Vitals. A page might have a correct LCP (quick hero image) but a disastrous Speed Index if the textual content takes 4 seconds to appear.

Product and design teams find Speed Index more illustrative than technical metrics. The filmstrip visualization concretely shows what the user sees second by second. This is helpful for convincing non-technical decision-makers of the importance of optimizations.

Should you still optimize Speed Index and FMP?

Prioritize optimizing LCP, it's the confirmed ranking signal. Speed Index generally improves as a side effect when you optimize LCP, but the reverse is not always true. First Meaningful Paint is obsolete; don’t waste time on it.

A winning strategy: use Speed Index as a UX quality control metric, not as the primary goal. If your LCP is good but your Speed Index is poor, dig deeper: you likely have a resource loading order issue.

What optimization mistakes should be avoided?

Do not load invisible content first to artificially improve Speed Index. Google detects attempts at gaming the metrics. Some sites show quick placeholders that inflate Speed Index but degrade the actual experience.

Be cautious with Web Fonts: they often block First Contentful Paint and impact Speed Index. Invisible text for 2 seconds ruins perceived speed. Use font-display: swap and preload critical fonts.

How to properly audit perceived mobile speed?

Run real tests on actual mid-range Android devices, not just in simulation mode. A Moto G4 with real 3G reveals invisible problems that a MacBook Pro in simulated 4G does not. Fluctuating network conditions dramatically change perception.

Compare Speed Index among competing pages in WebPageTest with filmstrip. You will see concretely who displays useful content faster. This is often more telling than a 200ms difference in LCP.

• Prioritize optimizing LCP (Core Web Vitals) before Speed Index
• Use Speed Index as a complementary UX indicator, not as a ranking metric
• Audit with Lighthouse in mobile throttling mode (simulated slow connection)
• Optimize loading order: main content above-the-fold first
• Preload critical resources (fonts, hero images) with preload/fetchpriority
• Test on real mid-range Android devices with actual connections