Why Your Mobile and Desktop Performance Scores Never Match

Same page, same audit tool, two very different numbers - a 90-something on desktop and something in the 50s or 60s on mobile. That's not a bug in the tool. Desktop and mobile tests measure genuinely different conditions on purpose, and the gap tells you something useful if you know how to read it.

Why the Numbers Diverge

A lab performance test isn't just "load the page and time it." It simulates a specific device and connection, and mobile and desktop simulate different ones on three axes:

• CPU throttling. Mobile tests apply a slowdown multiplier to approximate a mid-tier phone's processor, not a flagship. Desktop tests apply little to none, closer to the machine actually running the test.
• Network throttling. Mobile simulates a slower, higher-latency connection. Desktop assumes something closer to broadband.
• Viewport width. Mobile renders at 375px. That's not just a smaller canvas - it can change which responsive image size gets selected, trigger different layout and stacking behavior, and expose spacing or overlap issues that never show up at desktop widths.

Stack all three together and a page that's merely fine on desktop can look genuinely slow on mobile, even though it's the exact same HTML, CSS, and JS being requested.

Which Score Should You Actually Trust

For most sites, more of your real traffic is coming from an actual phone than the desktop score would suggest matters. And a real visitor's phone isn't a lab simulation - it's a genuinely mid-range or older device, on a genuinely inconsistent connection, sitting in someone's pocket on a train. The mobile lab test is trying to approximate that reality; the desktop test is largely measuring how fast your page can be under close-to-ideal conditions. If you can only act on one number, the mobile one is usually closer to how most visitors actually experience the page.

That doesn't make the desktop score useless - it's still the right one for catching problems that have nothing to do with device class, like a bloated JS bundle or an unoptimized image that's slow everywhere. It just shouldn't be the number you optimize toward if the two disagree.

What Matters More on Mobile Specifically

• JavaScript execution cost.A slower CPU means the same amount of JS takes meaningfully longer to parse, compile, and run. A bundle that barely registers on a desktop CPU can dominate Total Blocking Time and INP on a throttled mobile profile - the code is identical, the hardware isn't.
• Image weight. The same multi-megabyte hero image costs more time on a throttled connection than on broadband. Compression, responsive srcsets, and modern formats (AVIF/WebP) matter more on mobile precisely because the network is the constraint, not the render.

Field Data Splits by Device Too

This isn't only a lab-testing quirk. Real-user field data - the kind Search Console and the Chrome UX Report (CrUX) surface - is also segmented by device category, and it's common to see a site pass Core Web Vitals comfortably on desktop field data while failing on mobile field data for the same URLs. That's the same underlying gap showing up in real traffic instead of a lab simulation, which is one more reason not to treat a single blended score as the whole picture.

One mistake worth naming directly: don't compare a mobile lab score against a desktop field score, or vice versa, and conclude something changed. Keep the comparison within the same measurement type and the same device category, or the numbers aren't actually telling you what you think they are.

Reading a Report That Shows Both

A quick way to triage when you've got desktop and mobile numbers side by side:

• If a metric fails on both passes, the problem is in the page itself - a slow server response, an oversized bundle, missing dimensions on an image - and device class isn't the variable.
• If LCP or TBT/INP fails only on mobile, suspect JS execution cost or image weight first - those are the two factors that scale with throttling, not with layout.
• If CLS fails only on mobile, suspect the 375px layout specifically - something that reflows or stacks differently at that width, which desktop testing will never catch.
• Fix and re-test one pass at a time. A fix aimed at the mobile-only failure won't always move the desktop number, and that's expected, not a sign it didn't work.

Scanverra runs both passes in a single scan - a desktop run and a 375px mobile run under throttled conditions - so you get both numbers from one audit instead of two separate tools. The performance audit is the technical version with full Lighthouse metrics for both passes and framework-aware fixes; the website speed testis the same underlying data presented as one plain-language score if that's what you need to hand to someone non-technical.