Why are your Lighthouse mobile scores consistently lower than desktop?

Why isn’t this score difference a measurement issue?

The statement from Martin Splitt dispels a persistent myth: no, Lighthouse is not "tougher" on mobile due to algorithmic whim. The scores reflect a physical reality — mobile processors have less computing power, and network connections are often unstable or bandwidth-limited.

In practical terms, a site that loads in 1.2 seconds on a desktop i7 with fiber may take 4.5 seconds on a Moto G4 over slow 3G. Lighthouse simulates these real conditions, hence the sometimes brutal score disparity. This isn't a measurement error; it reflects the majority user experience.

What does the "smallest common denominator" mean in this context?

Mobile represents the most constraining scenario: limited CPU, variable networks, battery to conserve. If your site performs well on mobile, it will perform well on desktop. The opposite is not true.

Google therefore applies the principle of mobile-first indexing: the index is built on the mobile version, and the Core Web Vitals measured in real conditions primarily come from mobile traffic. Optimizing for desktop alone means ignoring 60-70% of your actual visitors — and the majority of the ranking signal.

Are Lighthouse desktop scores useless then?

Not useless, but less representative of reality. A desktop score of 95 can mask a catastrophic mobile score of 42. Yet it is mobile that matters for indexing, CrUX, and thus ranking.

Desktop remains relevant for diagnosing certain structural issues (blocking JavaScript, unoptimized CSS) that affect both platforms. But true validation occurs on mobile — this is where your weaknesses appear mercilessly.

• Mobile scores reflect real hardware constraints, not an algorithmic bias.
• Mobile is the common denominator for Google indexing and ranking.
• A good desktop score guarantees nothing if mobile is poor — the reverse is true.
• Core Web Vitals in real conditions come primarily from mobile traffic, that's the signal that matters.
• Optimizing for mobile automatically covers desktop; the reverse strategy often fails.

Is this statement consistent with real-world observations?

Absolutely. All SEOs who regularly audit see the consistent gap between mobile and desktop scores — often a 20 to 40 point difference. Splitt’s statement confirms what the field has been showing for years: mobile is structurally more demanding.

Let’s be honest: many sites display an honorable desktop score (70-85) and collapse on mobile (30-50). This is no coincidence; it's the signal of a tech stack designed desktop-first. Unoptimized images, heavy JavaScript, unpreloaded web fonts — all of these can pass "just fine" on desktop and become prohibitive on mobile.

What nuances should be added to this rule?

The statement remains general. It doesn’t specify what score gap is acceptable — 10 points? 30 points? Google provides no threshold. [To verify] on your own CrUX data: a significant gap can indicate a structural problem even if the mobile score stays "green".

Another nuance: some desktop-only sites (B2B SaaS tools, business applications) have marginal mobile traffic. For them, prioritizing mobile makes no business sense. But beware — Google still indexes the mobile version by default. You must ensure that the mobile version exists and remains functional even if it is not the primary target.

In what cases might this mobile-first logic falter?

On sites with a strong interactive or application component. A web CRM, an online photo editor, a data visualization platform — these tools are designed for desktop, with a mouse, large screens, and CPU power. Forcing a mobile optimization could degrade the primary user experience.

In these cases, it’s necessary to negotiate between SEO signal and actual UX. A hybrid solution: a functional yet simplified mobile version, with a redirect to desktop for advanced features. Or accept a mediocre mobile score if organic mobile traffic is negligible — but document this strategic choice to avoid false alerts in audits.

What specific actions should you take to improve mobile scores?

Start by identifying CPU bottlenecks: heavy JavaScript, complex animations, poorly optimized client-side frameworks. Lighthouse will give you the "Opportunities" and "Diagnostics" — prioritize those with the greatest impact in seconds saved.

Next, optimize network resources: compress images (WebP, AVIF), lazy-load everything off the initial viewport, pre-load critical fonts. A site that loads 3MB of resources on mobile is prohibitive — aim for less than 1MB for the First Contentful Paint.

What mistakes should you absolutely avoid?

Don’t just test on your iPhone 15 Pro over Wi-Fi. Lighthouse simulates a Moto G4 over slow 4G — this is far from your daily setup. Test on real mid-range devices with network throttling activated.

Another pitfall: focusing solely on the overall score and ignoring individual metrics. A catastrophic LCP at 6 seconds can coexist with an "orange" score of 65. Target the metrics that hurt the actual experience (LCP, CLS, TBT), not just the overall number.

How can you check if your mobile-first strategy is paying off?

Compare your real CrUX data vs. Lighthouse lab. If your mobile Lighthouse score is 55 but your actual CrUX shows 80% of users as "Good", your visitors probably have more powerful devices than the simulated Moto G4 — you're likely okay.

Conversely, a Lighthouse score of 70 but a catastrophic CrUX indicates a problem: real network conditions worse than the simulation, or traffic on even weaker devices. Audit your traffic mix: countries, carriers, devices. Core Web Vitals can be segmented in Search Console.

• Audit Lighthouse mobile first, desktop second.
• Focus on LCP, CLS, and TBT — these are the metrics that count for ranking.
• Test on real mid-range devices, not just your personal flagships.
• Compress images and defer all non-critical JavaScript — under 1MB for the initial viewport.
• Monitor real CrUX vs. Lighthouse lab to validate that your optimizations translate into real experience.
• Document your choices if your site is desktop-only by design — own the decision-making rather than just enduring the alert.