Why are your mobile Lighthouse scores consistently lower than on desktop?

Why does Lighthouse penalize mobile more than desktop?

The score difference between mobile and desktop is not arbitrary. Lighthouse applies CPU throttling on mobile tests — it intentionally limits computing power to simulate a mid-range device.

The goal? To replicate the real-world conditions of a user browsing from a smartphone on 4G, not from a MacBook Pro connected via fiber. Mobile processors are less powerful, connections are more variable, and battery life is limited. The test reflects this on-the-ground reality.

What exactly is CPU throttling?

CPU throttling is a technique that artificially slows down the processor during the Lighthouse test. By default, the tool applies a 4x slowdown factor on mobile.

The result: a JavaScript script that executes in 100ms on desktop will take 400ms in the mobile test. This delay directly impacts metrics such as Total Blocking Time (TBT) or Time to Interactive (TTI), which weigh heavily in the final score.

Should we ignore desktop scores and focus solely on mobile?

Since the widespread mobile-first indexing, Google primarily crawls and evaluates the mobile version of your site. Desktop scores still matter for user experience on computers, but they do not reflect Google's assessment lens.

In practice, a site that performs brilliantly on desktop but collapses on mobile is a poorly optimized site. The opposite — performing well on mobile, average on desktop — poses fewer problems for SEO. Mobile dictates the rules of the game.

• Mobile Lighthouse scores include 4x CPU throttling to simulate real-world conditions
• Mobile devices account for the majority of web traffic and are the priority evaluation criterion for Google
• A gap of 20-30 points between mobile and desktop is normal and expected
• JavaScript-intensive metrics (TBT, TTI) are particularly impacted by throttling
• Optimizing for mobile mechanically improves desktop performance; the reverse is rarely true

Is this statement consistent with real-world observations?

Absolutely. Any professional who regularly audits sites notices this systematic gap between mobile and desktop scores. Martin Splitt's statement validates what has been observed for years.

The problem is that many clients or decision-makers discover PageSpeed Insights, see a desktop score of 95 and a mobile score of 65, and scream bug. It's not a bug — it's a true reflection of a site that is not optimized for mobile constraints.

What nuances should be added to this rule?

The 4x throttling by Lighthouse is an arbitrary standard. An iPhone 14 Pro will outperform a low-end Android smartphone released in 2019. The tool simulates a mid-range device, not a flagship or a budget model.

Specifically, if your audience mostly uses recent devices and stable connections, mobile Lighthouse scores may be more pessimistic than the actual conditions. Conversely, if you target emerging markets with old devices and unstable 3G, Lighthouse might still be too lenient. [To be verified] with the real data from the Chrome User Experience Report (CrUX) for your domain.

In what cases does this rule not fully apply?

Desktop-only sites (business applications, back-office, professional tools) can legitimately ignore mobile scores if 95% of their traffic is desktop. But let's be honest: these cases are rare.

For public-facing sites, e-commerce, media, services — around 90% of the web — mobile performance is paramount. A catastrophic mobile score indicates a structural problem: blocking JavaScript, unoptimized images, slow server, critical CSS missing. These issues also impact desktop, just less visibly.

What should be done concretely to improve mobile scores?

Prioritize JavaScript. It's the element that kills mobile performance via CPU throttling. Every third-party library, every tag manager, every social widget adds to TBT. Audit your scripts, eliminate unnecessary dependencies, load everything that is not critical in defer or async.

Optimizing images becomes even more crucial. On mobile, a 2MB JPEG image already loads slowly — but it's the CPU that has to decode and render it afterward. Switch to WebP or AVIF, size correctly with srcset, and lazy-load everything that is outside the initial viewport.

What mistakes should be absolutely avoided?

Do not test only on your iPhone 15 on fibre Wi-Fi. Use Chrome DevTools with throttling enabled, or better, a real mid-range Android device. The gap between your development environment and user reality is often vast.

Avoid loading render-blocking CSS or JavaScript for secondary features. The homepage carousel, chat bot, fancy animations — all these can wait until the main content is displayed. Prioritize the Above the Fold mobile.

How do I check if my site is properly optimized for mobile?

Compare your Lighthouse scores with your real CrUX data. If you meet the Core Web Vitals thresholds (LCP < 2.5s, FID < 100ms, CLS < 0.1) based on real field data, you're good to go — even if Lighthouse mobile is complaining.

Use PageSpeed Insights that combines both: Lighthouse lab score AND CrUX field data. If the gap is huge, dig deeper. A good lab score but catastrophic Core Web Vitals in the field signals a problem with network or device variability that you are not replicating in tests.

• Audit and reduce blocking JavaScript (overly heavy bundles, unnecessary libraries)
• Implement lazy-loading on all images outside the initial viewport
• Convert images to WebP or AVIF with adaptive srcset
• Extract and inline critical CSS for Above the Fold mobile
• Test with CPU throttling enabled in Chrome DevTools ("4x slowdown" option)
• Validate Core Web Vitals with the real CrUX data from your domain