Why Your Mobile PageSpeed Score Refuses to Budge (Even After Desktop Hits 95+)

If you've ever optimized a site and watched the desktop PageSpeed Insights score climb to 95-100 while mobile sits stuck at 45-60 on the exact same page, you've run into one of the most common — and most misunderstood — problems in web performance. It's not a bug, and it's not because your mobile CSS is worse. Mobile is graded on a fundamentally harder test, on purpose, and once you understand the mechanics, you stop wasting time chasing the wrong fixes.

I run wordpressspeedoptimizationservice.com, and this exact gap — desktop scoring great, mobile stuck in the 40s to 60s on the identical page — is the single most common thing that confuses people the first time they actually read their own PageSpeed report.

There are two separate reasons mobile scores are harder, and it's easy to conflate them: one is about how the lab test itself is built, and the other is about how real mobile users actually experience your site. Fixing the first without understanding the second gets you a great Lighthouse number and a site that still frustrates real visitors — which matters, because Google's actual ranking signal comes from that second, real-user layer, not the lab score.

PageSpeed Insights is really two different tests wearing one UI

When you run a URL through PageSpeed Insights, you get two reports: mobile and desktop. Both use the same underlying engine, Lighthouse, but run it against deliberately different simulated conditions.

Same page, two very different obstacle courses. Below the lab scores, PSI also shows field data pulled straight from the Chrome UX Report (CrUX) — real Chrome users, no simulation involved. That section shows a mobile penalty too, for completely different reasons. Let's take the lab gap first, then the real-world one.

Part 1: Why the lab score is engineered to be harder on mobile

CPU throttling, and a recalibration most people missed. By default, Lighthouse slows the CPU down during a mobile test to simulate a weaker device, even when it's actually running on fast hardware. The generic Lighthouse default is a 4x slowdown multiplier. But the PageSpeed Insights tool most people actually use — pagespeed.web.dev — hasn't used that default since December 2024.

Google recalibrated it because PSI's own test servers already benchmark as fairly weak CPUs compared to a typical developer's laptop; stacking a full 4x penalty on top of already-weak server hardware was over-throttling sites well past what a real mid-tier phone experiences.

So Google brought the multiplier down — DebugBear's independent analysis puts the new figure around 1.2x — specifically to land back on the same target: a realistic mid-tier device, not an artificially punishing one. Google's own release notes confirm the change and its purpose, noting that it leaves field data and desktop scores untouched. Practical implication: a Lighthouse run from Chrome DevTools on your own laptop (still 4x by default) and a PSI report on the same URL are not applying the same throttle. That mismatch alone explains a chunk of the "my local test looks fine but PSI disagrees" confusion.

Network throttling. Mobile tests also simulate a slow connection, currently labeled "Slow 4G" in Lighthouse (the same profile that used to be called "Fast 3G" — it wasn't loosened, just renamed for clarity). It runs at roughly 1.6 Mbps down / 750 Kbps up, deliberately calibrated to sit at the slow end of typical 4G and the fast end of typical 3G — closer to something like an 85th-percentile mobile experience than a median one. Desktop testing uses a much faster simulated connection. Every request your page makes — render-blocking scripts, web fonts, redirect chains — gets stretched by this slower pipe on mobile in a way desktop testing never sees.

Device emulation. Alongside the throttling, Lighthouse emulates a specific mid-tier phone's screen size and user agent. That target device has moved over the years — a Nexus 5X originally, a Moto G4 starting in 2020 (Lighthouse 6), and the Moto G Power starting in 2023 (Lighthouse 10) — and Moto G Power remains the reference device as of the current Lighthouse 13 releases. It's a deliberate, actively maintained choice meant to track a realistic "not flagship, not bottom-shelf" phone, not an arbitrary handicap.

The scoring weights pile onto exactly what throttling punishes hardest. The Lighthouse performance score is a weighted blend of five metrics:

TBT alone carries the single heaviest weight, and that's not arbitrary. Google's real interactivity metric, INP, can only be measured from an actual person clicking or tapping something — there's no interaction to observe during an automated lab run with nobody there. TBT is Lighthouse's stand-in: it measures how long the main thread was too busy to respond if a person had tried to interact.

Here's where it compounds. TBT is fundamentally a measurement of JavaScript execution time on the main thread, and JS execution is CPU-bound — it gets faster with a faster processor, not a faster connection. So the single metric most directly determined by raw CPU power also happens to be the one weighted highest in your entire score.

Throttle the CPU, and you're not slowing the page down evenly across the board — you're taking a direct hit on 30% of the grade before LCP (frequently JS-blocked too) and CLS pile on another 50%. A third-party script that adds a couple hundred milliseconds of blocking time on an unthrottled desktop run can easily add several times that once the identical execution is spread across a throttled mobile CPU, before the slower network even factors in.

One more nuance worth knowing: mobile and desktop don't literally share a scoring curve. Since Lighthouse 6, each is scored against its own calibration of real-world HTTP Archive data, so a given raw metric value doesn't map to the same score on both.

That's not Google grading mobile more harshly — it just means the two numbers were never meant to be compared 1:1 in the first place. The gap you actually see comes mostly from the throttled test producing genuinely worse raw numbers, which then get scored, fairly, against a mobile-appropriate curve.

Part 2: Why real mobile users have it harder too — this isn't just a testing artifact

It would be convenient if this were purely a lab-test quirk you could shrug off. It isn't. Look at the field data — real Chrome users, zero simulation — and mobile still trails desktop by a wide, persistent margin. In the most recent HTTP Archive Web Almanac figures, roughly 48% of mobile origins pass all three Core Web Vitals, against roughly 56% of desktop origins. That gap has held for years, for reasons that have nothing to do with how Lighthouse happens to be configured.

The hardware spread is enormous, and "mid-tier" is closer to the fast end than most builders assume. A flagship iPhone or Galaxy is genuinely close to laptop-class performance for everyday browsing. But global mobile traffic includes a huge volume of budget Android devices, commonly in the low hundreds of dollars, where the CPU is a fraction as capable.

One academic study measuring real device performance found JavaScript processing time on low-end phones running roughly three times slower than on desktop hardware, for the identical script. If your team is testing on recent iPhones, the gap between what you see and what a meaningful slice of your real mobile traffic experiences can be bigger than the gap between your own desktop and mobile Lighthouse scores.

Real mobile networks add latency and variability no fixed connection has. Median mobile throughput has genuinely improved with 5G in well-covered areas, so raw download speed isn't always the bottleneck it used to be.

Latency is the more persistent gap: mobile connections typically run tens of milliseconds slower round-trip than fixed broadband or fiber, and unlike a desk-bound wifi connection, that latency fluctuates constantly with signal strength, cell congestion, and whether the person is walking, driving, or standing somewhere with weak reception.

Every round trip on the way to a usable page — DNS lookup, TLS handshake, a redirect chain, a script that has to finish before the next request even starts — gets more expensive and less predictable under those conditions than a single lab run can fully capture.

Put together, this is why a "just fix the lab score" mentality only gets you partway. Even a page that scores 100 on Lighthouse mobile was tested against one specific mid-tier device on one specific throttled connection. Your actual mobile traffic spans a much wider range than that — and on the low end, a meaningfully worse one.

What this actually means for what you fix first

Given all of that, the mobile-specific priority list looks different from a generic "make the site faster" checklist:

Attack JavaScript before anything else, especially third-party scripts. Chat widgets, ad tags, analytics snippets, and consent banners all run on the same throttled main thread as your own code, and TBT is 30% of the score. Defer or lazy-load anything not needed for first paint, and audit third-party scripts specifically — they're frequently the single biggest main-thread cost on an otherwise lean codebase.

Treat server response time (TTFB) as more important on mobile, not less. Higher, more variable network latency amplifies server response time instead of absorbing it the way a stable wifi connection might. Fast, well-cached hosting matters more on mobile, not less.

Serve genuinely smaller images to mobile viewports, not just compressed ones. A hero image sized for a 1600px desktop layout and squeezed into a 400px mobile viewport with CSS still costs the same bytes and the same decode time. Responsive images (srcset/sizes, or a CDN/plugin that automates it) actually send a smaller file to a smaller screen.

Test with real throttling locally instead of trusting a fast dev machine. An unthrottled run on a MacBook tells you almost nothing about what ships to a mid-range Android phone on a spotty connection. Lighthouse even publishes a CPU calibration tool for exactly this reason — "4x on my machine" and "4x on PSI's servers" were never the same throttle.

Stop expecting mobile and desktop to converge. They're testing different things by design. The realistic goal isn't matching your desktop number — it's clearing the actual Core Web Vitals thresholds (LCP under 2.5s, CLS under 0.1, a responsive INP) under the conditions real mobile users are on, which is a genuinely harder bar and worth budgeting real time for.

The gap between your mobile and desktop scores isn't a sign something's broken. It's the tool doing exactly what it's designed to do: showing you the version of your site that a mid-tier phone on a mediocre connection actually has to load. Uncomfortable, but a far more useful number than a desktop score that mostly just reflects your own laptop.