Why Your Site Scores 90 on Desktop and 55 on Mobile

You run your homepage through PageSpeed Insights. Desktop comes back green at 92. You click the Mobile tab and it drops to 55.

Same page. Same server. Same code.

The first assumption is usually that something is broken on mobile. Usually nothing is. Most of the gap is the test itself, plus a handful of things that get expensive the moment a real phone is involved.

What changes when Lighthouse switches to mobile

PageSpeed Insights doesn’t run one test and relabel it. It runs your page under two different simulated conditions and scores each separately. Desktop assumes a fast machine on a fast connection. Mobile assumes a mid-range phone on a mediocre 4G signal.

Lighthouse, the engine behind it, uses fixed presets for each:

Test condition	Mobile	Desktop
Download speed	1.6 Mbps	~10 Mbps
Round-trip latency	150 ms	40 ms
CPU multiplier	4×	1×
Viewport width	412 px	1350 px

The network preset Google calls Slow 4G is roughly the bottom 25% of 4G connections, according to Lighthouse’s docs. Desktop gets about six times the bandwidth and less than a third of the latency.

The CPU throttling matters more. Lighthouse applies a 4× slowdown on mobile to approximate a mid-tier phone, while the desktop profile uses 1× and gets no artificial slowdown at all. CPU-heavy work becomes dramatically more expensive as a result.

Nothing about your code changed. The processor pretending to run it just got much weaker.

The rest of the report is still worth reading. The individual warnings and diagnostics point at real problems. The score gap usually isn’t one of them.

Desktop is graded harder, not easier

You might assume mobile scores lower because Google grades it more strictly. It’s the opposite. Lighthouse uses separate scoring curves for each mode, and the desktop curves are tighter, because a desktop is expected to be fast.

Google’s documentation spells it out. For Largest Contentful Paint (LCP — how long until the biggest visible element finishes rendering), a green result means under 2.5 seconds on mobile, but under 1.2 seconds on desktop. The stated reasoning is that Lighthouse is a lab tool, so it’s useful to be stricter when testing the faster device.

So the mobile score isn’t lower because the bar is higher. It’s lower because the simulated device is slow enough that even a generous bar is hard to clear.

JavaScript is often where the gap comes from

Total Blocking Time (TBT — how long the main thread is stuck and unable to respond to input) carries the heaviest weight in the score at 30%. LCP and Cumulative Layout Shift (CLS) sit at 25% each, and First Contentful Paint (FCP) and Speed Index take 10% each.

TBT measures main-thread blocking, not JavaScript specifically. But on WordPress sites it’s usually JavaScript doing the blocking, and JavaScript is exactly the kind of work a slower processor exposes. Downloading a 300 KB script over Slow 4G is survivable. Parsing, compiling, and executing it on a throttled CPU is where the seconds pile up.

That’s why a page can look almost identical on the paint metrics in both reports, then collapse on TBT.

A typical WordPress stack gets there without anyone deciding to. Your theme ships jQuery, your page builder ships its own bundle, and a form plugin, a slider, a cookie banner, and an analytics tag each add their own. None feels heavy alone. Together, they’re the score.

Third-party code is punished twice here: slower to fetch and slower to execute. Chat widgets, heatmap trackers, ad tags, tag managers, it’s surprisingly common to find scripts that were added for an old campaign and never removed.

Your images are sized for a screen nobody’s using

Another common contributor, and much easier to fix.

Upload a 2400px hero image and serve it to everyone, and the desktop test barely blinks. The mobile test downloads the same file over a 1.6 Mbps connection to display it in a 412px-wide viewport.

WordPress adds responsive sizes and srcset markup automatically for images inserted through its own image functions, so a lot of this is handled. Problems show up in two places:

• CSS background images, which don’t get that srcset handling. They can be made responsive with media queries or image-set(), but unless your theme or builder does that, the full-size file goes to every device.
• Page builder modules, which sometimes hardcode a size or bypass WordPress’s responsive markup.

One mistake deserves its own line: never lazy-load your LCP image. Adding loading=”lazy” to the hero delays the exact thing the metric is measuring.

Render-blocking CSS costs more on a slow connection

A browser won’t paint anything until it has the CSS it needs. On a fast connection, fetching a 200 KB stylesheet is a rounding error. At 1.6 Mbps with 150 ms latency, it’s a visible delay before anything appears on screen, and it pushes back FCP and LCP together.

That’s the problem CSS Critique solves: extract only the styles needed for the visible part of the page, inline them in the HTML, and let the rest load in the background.

Fonts behave the same way. Every external font request adds a DNS lookup, a connection, and a download before text can render in its final form, and each step costs more at 150 ms latency than at 40 ms. Self-hosted fonts remove that extra connection. The file still has to download, so limiting variants and controlling how they load matters too.

Layout shifts that only happen on small screens

CLS measures how much your content jumps around while the page loads, and it’s worth 25% of the score. A 1350px viewport absorbs movement: elements sit side by side, there’s whitespace to spare, and a late banner nudges things slightly.

At 412px everything is stacked in a single column, so one element loading late pushes everything below it down the page. The same element can produce a much larger CLS impact on mobile simply because there’s less space to absorb the movement.

Common culprits:

• Cookie banners and notification bars that inject themselves after first paint
• Sticky headers that change height once JavaScript initializes
• Images and embeds without explicit width and height attributes
• Web fonts swapping in and changing line heights
• Mobile menus that expand or reposition on load

Hidden elements still download

Hiding something with display: none at mobile breakpoints doesn’t reliably stop the browser downloading it. Scripts and stylesheets are referenced in the markup, so they get fetched before any CSS decides what to hide. An <img> inside a hidden container is generally still fetched too, though a CSS background-image on a hidden element usually isn’t.

Some themes render both a desktop navigation and a separate mobile one, then hide one with CSS. The mobile visitor pays for both.

If a section shouldn’t exist on mobile, it needs to be conditionally loaded, not conditionally hidden.

How big a gap is actually normal?

A noticeable gap is normal. A difference of 20 points or more doesn’t automatically mean something is wrong with your site.

What matters is where those points are being lost. If desktop scores 92 and mobile scores 72 because everything simply takes longer under throttling, there may be nothing to worry about. If mobile drops to 55 because TBT explodes or the LCP image takes several seconds to arrive, the gap is telling you something useful.

So don’t diagnose your site from the size of the gap. Open the mobile report and look at which metrics are losing the points, and keep in mind that a single run isn’t a measurement. Lighthouse scores vary between runs even when nothing on the page has changed, so test several times and use the median.

Chasing a perfect 100 isn’t worth it either. A solid mobile score with passing Core Web Vitals from real visitors beats a lab number.

And if GTmetrix and Lighthouse hand you three different scores for the same page, that’s a separate problem with its own explanation.

What to fix first

Work in this order. It’s roughly sorted by points gained per hour spent.

1. Cut JavaScript execution. TBT is 30% of the score and it’s the metric mobile punishes hardest. Remove plugins you don’t use, defer non-essential scripts, and delay third-party code until after interaction.
2. Fix the LCP image. Compressed, served in WebP or AVIF, sized for mobile, and not lazy-loaded.
3. Inline Critical CSS and defer the rest. This targets FCP and LCP together, and it’s where slow connections hurt most.
4. Reserve space for anything that loads late. Set explicit dimensions on images and embeds, and give banners and sticky elements a fixed height.
5. Audit third-party scripts. Remove what you’re not using. Delay what you can’t remove.
6. Check what’s loading but hidden. Anything downloaded and then hidden at mobile breakpoints is pure waste.

You can do all of this by hand. The downside is that performance optimization has a habit of turning into a maintenance job of its own, and it tends to come undone the next time you update your theme.

That’s where automation helps. FastPixel does all this and fixes your issues on autopilot. It generates Critical CSS per page, defers JavaScript, optimizes fonts, and resizes and delivers images in next-gen formats through the ShortPixel CDN, processing pages for different screen sizes rather than assuming one output fits every device.

The bottom line

The gap isn’t a bug. It’s what happens when the same page is measured on a mid-range phone with a throttled processor and a mediocre connection.

Some of it is just the test. The rest is JavaScript your visitors don’t need, images bigger than any phone will display, and CSS that blocks rendering longer than it should. Open the mobile report, find which metrics are bleeding points, and start there.

The score isn’t the real problem. The visitor on a slower phone, waiting for your page to appear, is.

FAQs

Is a big gap between mobile and desktop normal?

Yes. A gap of 20 points or more is common even on well-maintained sites, because the mobile test simulates a much slower device on a much slower connection. What matters is which metrics are losing the points, not the size of the gap. A score that drops mainly on TBT is telling you something very different from one that drops on CLS.

Does Google use my mobile or desktop score for rankings?

Neither, directly. Your Lighthouse performance score isn’t a ranking signal. Google does use Core Web Vitals as part of its ranking systems, but those come from real-world user experience rather than the 0–100 number in Lighthouse. Use the score to find problems, then watch the Core Web Vitals data from your actual visitors. That data is reported separately for phone and desktop, so if your traffic skews mobile, that’s the segment to prioritize.

Why does my score change every time I run the test?

Lighthouse results vary between runs on a page that hasn’t changed at all. Server response times, network conditions, third-party script timing, and general browser nondeterminism all contribute. Run the test several times and use the median rather than reading anything into a single result.

Should I bother optimizing for desktop at all?

If your desktop score is already 90+, your effort is better spent on mobile. Almost every mobile fix also helps desktop, and the reverse isn’t reliably true. If desktop is below 80, something is wrong that’s affecting everyone.

Will a responsive theme fix my mobile score?

No. Responsive design changes how your page looks at different widths. It doesn’t change how much JavaScript executes, how large your images are, or how much CSS blocks rendering. A perfectly responsive site can still score badly on mobile.

My mobile score looks fine but Search Console says my Core Web Vitals are poor. Which is right?

Both, measuring different things. The Lighthouse performance score in PageSpeed Insights is lab data from a simulated test, while Search Console reports Core Web Vitals collected from real visitors on real devices. When they disagree, prioritize the field data and use the Lighthouse report to diagnose what’s causing it. Worth knowing: PageSpeed Insights shows you both in the same report, so you can often compare them without opening Search Console at all.