Why Is Your Mobile Score Lower Than Desktop?
Almost every site scores worse on mobile, and the reflex is to assume something is broken. Usually nothing is. The mobile test is simply a much harder test, deliberately calibrated to hardware and networks that many real users actually have and that developers on fast laptops never experience.
What does mobile throttling actually simulate?
Lighthouse mobile applies a CPU slowdown multiplier and a simulated slow 4G network with added latency, approximating a mid-tier Android phone. Desktop runs with far lighter throttling. The same JavaScript bundle therefore takes several times longer to parse and execute in the mobile test.
Because CPU throttling multiplies main-thread work, sites heavy in JavaScript see the gap widen disproportionately. A page dominated by images and HTML narrows the gap considerably, since transfer time scales with bandwidth rather than with processor speed.
How big a gap is normal?
A difference of twenty to thirty points between desktop and mobile is unremarkable for a content site. Gaps beyond forty points usually indicate heavy client-side JavaScript, large unoptimised images being served at desktop dimensions, or third-party scripts that block the main thread.
Rather than comparing the two scores, look at which individual metrics diverge. If Total Blocking Time collapses on mobile while LCP holds up, the problem is script execution. If LCP collapses too, resource size and network are implicated as well.
Which should you optimise for?
Mobile, in nearly all cases. Google indexes mobile-first, mobile field data typically drives the Core Web Vitals assessment, and most consumer traffic arrives on phones. Desktop scores rarely fail once mobile passes, so optimising mobile improves both.
The exception is genuinely desktop-dominant products, internal tools, professional software, some business services, where mobile traffic is negligible. Even there, mobile scores remain a useful stress test that exposes inefficiency the fast path hides.
What closes the gap fastest?
Ship less JavaScript. Code-split so each page loads only what it needs, defer non-essential third-party scripts, and remove libraries that duplicate native capability. Then serve responsive images sized for the device rather than sending desktop-dimension files to a phone.
Third-party scripts deserve separate scrutiny because they are invisible in your own codebase and often added without performance review. Auditing what tags actually load, and removing those nobody uses any more, is frequently the largest single available win.
Key takeaways
- Mobile testing throttles CPU and network far harder than desktop by design.
- A twenty to thirty point gap is normal; beyond forty suggests JavaScript weight.
- Compare individual metrics across the two rather than the composite scores.
- Optimise for mobile, since it drives both indexing and the vitals assessment.
- Reducing JavaScript and auditing third-party tags closes the gap fastest.
Frequently asked questions
- Does Google use the mobile or desktop score?
- Neither directly, since the Lighthouse score is not a ranking signal. Google uses Core Web Vitals field data, which is reported separately for mobile and desktop. With mobile-first indexing, mobile field data is the one that generally determines the assessment for a page.
- Can a responsive site still score badly on mobile?
- Easily. Responsive design controls layout, not payload. A responsive page that still downloads the full desktop JavaScript bundle and full-size images performs poorly on a throttled phone despite looking correct. Responsiveness and performance are independent properties.
- Why is my real phone faster than the Lighthouse mobile test?
- Because the test simulates a mid-tier device on slow 4G, and a recent flagship on good WiFi is considerably faster. The simulation deliberately models a slower experience than most developers have. That is the point: it approximates the visitors who struggle.
- Should I serve a separate mobile site?
- Generally no. Separate mobile sites add URL duplication, canonical complexity and maintenance cost, and Google has recommended responsive design for years. Achieve the payload difference with responsive images and conditional loading rather than a parallel site.
Web Performance, BigBalli. We track Core Web Vitals definitions and thresholds as Google revises them, cross-checked against web.dev and Chrome developer documentation.