Fast on Desktop, Slow on Mobile: What's Actually Different (2026)

Lighthouse runs its mobile test on a simulated mid-range Android with the CPU slowed to a quarter of its real speed and the connection capped at 1.6 Mbps. The desktop test runs at full CPU speed on a 10 Mbps line. Same page, same server, same code, two completely different exams. So the first thing to say about a site that scores green on desktop and red on mobile is that nothing has necessarily broken. You are looking at the gap between an easy test and a hard one.

That does not mean the gap is meaningless. It means the gap is diagnostic. Once you know exactly how the two tests differ, the size of the difference between them tells you which of four things is wrong with the page — and three of those four are fixable without touching the platform underneath.

What the mobile test actually does to your page

The numbers are published. Lighthouse's throttling documentation sets the default mobile preset at 150 ms latency and 1.6 Mbps down / 750 Kbps up, which it describes as roughly the bottom quarter of 4G connections. On top of that it applies a constant 4x CPU slowdown multiplier, and it emulates a Moto G Power handset at a 412-pixel-wide viewport with a device pixel ratio of 1.75.

The desktop preset, defined in the same source, uses 40 ms latency, 10 Mbps throughput, a CPU slowdown multiplier of 1 — no slowdown at all — and a 1350-pixel viewport at a device pixel ratio of 1.

Read those side by side and the picture is stark. The mobile run gives your page roughly a sixth of the bandwidth, nearly four times the round-trip latency, and a quarter of the processing power. A page that is doing a lot of work will look fine in the first environment and fall apart in the second, because the second one is where the work becomes visible.

This is not Lighthouse being unfair. It is Lighthouse deliberately modelling the phone that a real customer in regional Victoria or on a suburban train is holding, rather than the machine your web designer built the site on.

The four things that actually cause the gap

1. JavaScript, because CPU is the thing that really differs

Bandwidth gets all the attention and it is the smaller half of the problem. Downloading a 400 KB JavaScript bundle over a throttled connection costs you a couple of seconds. Parsing it, compiling it and executing it costs you the CPU time — and that is where the 4x multiplier bites.

Critically, this work happens on a single thread. While the browser is executing your scripts, it is not painting, not responding to taps, not doing anything else. On a desktop CPU that block of work disappears into the noise. On a mid-tier Android it becomes a visible freeze: the page appears, the customer taps the enquiry button, and nothing happens for most of a second because the main thread is still busy.

This is why the mobile-versus-desktop gap almost always shows up worst in Interaction to Next Paint and Largest Contentful Paint, and often barely at all in Cumulative Layout Shift. Layout shift is a design fault and it hurts both form factors equally. INP and LCP are the two metrics that are hostage to processing power. Google's current Core Web Vitals thresholds put "good" at 2.5 seconds for LCP, 200 milliseconds for INP and 0.1 for CLS — and 200 milliseconds is not much of a budget once a phone CPU is involved.

2. Images sized for the screen you designed on

The mobile emulation runs at 412 CSS pixels wide with a device pixel ratio of 1.75, which means a genuinely full-width image on that device needs about 721 actual pixels of detail. Not 2400. Not 1600.

The common failure is a hero image exported at desktop dimensions, dropped into the page with a single source, and then squeezed down by CSS at display time. The browser still downloads the whole thing. On desktop that is wasteful but survivable at 10 Mbps. At 1.6 Mbps it is the difference between a fast page and a slow one, and it is usually the single largest line item in a site's total page weight.

The fix is unglamorous and it is not a rebuild: serve several sizes of each image and let the browser pick, using the width and pixel-density information the browser already has. Combine that with a modern image format and it is common to cut the bytes on an image-led page by more than half without any visible loss of quality. Lighthouse names the specific files under its "properly size images" audit, which is where to confirm this one before you spend a day on it. Our free audit reports total page weight, which is a quicker way to tell whether images are the line item worth looking at first.

3. Third-party scripts you have stopped noticing

Chat widgets, booking engines, review carousels, analytics, ad pixels, heat-mapping tools, hosted fonts, cookie consent banners. Each one was added for a defensible reason and each one adds a request, then a script, then main-thread execution time that your phone visitors pay for.

The scale of this is well documented. The HTTP Archive's 2024 Web Almanac found that "the percentage of pages with one or more third parties remains high at 92%", with a median of 27 third parties per page across the top million websites. It also found that the median depth of third-party inclusion chains is 3.4 — meaning the average site is loading scripts that load other scripts that load other scripts, most of which nobody at the business has ever chosen.

Third parties are also the reason a mobile score can drop overnight without anyone touching the site. A vendor ships a heavier version of their widget, and your page inherits the cost. Desktop absorbs it. Mobile does not.

The diagnostic here is quick: in the Lighthouse report, open the treemap or the third-party summary and sort by main-thread blocking time. If a booking widget or a chat tool is at the top of that list, you have found your gap, and the conversation is about whether that tool earns its cost rather than about your hosting.

4. You are comparing the wrong two numbers

This one is not a fault in the page at all, and it wastes more time than the other three combined.

PageSpeed Insights shows you two things that look similar and are not. The lab result is a single simulated run using the throttling above. The field result is real data from real Chrome users, and Google's PageSpeed Insights documentation is explicit that it reports FCP, INP, LCP and CLS "over the previous 28-day collection period". That field data is segmented by form factor — the Chrome UX Report breaks results into phone, tablet and desktop — and it is what feeds the page experience signal.

So there are actually four numbers in play, not two: lab mobile, lab desktop, field mobile, field desktop. A site can have an ugly lab mobile score and perfectly healthy field mobile data, because the simulated device is harsher than the average phone your actual customers use. It can also run the other way, which is the one worth worrying about: a decent lab score alongside poor field data means real people on real Australian networks are having a worse time than the simulation predicted, usually because of something the lab run never encountered — a logged-in state, a slow API, a regional CDN gap.

Before you spend money, work out which of those four numbers moved. We have written up that separation in more depth in the piece on diagnosing a sudden Core Web Vitals drop, because it is the same trap in a different costume.

Why the mobile number is the one that counts

There is a temptation to look at a desktop score of 90-something and decide the site is fine. Google does not read it that way. Its own guidance on mobile-first indexing states plainly that "Google uses the mobile version of a site's content, crawled with the smartphone agent, for indexing and ranking".

The desktop score is a courtesy. The mobile score is the one attached to the version of your page that gets crawled, evaluated and ranked — and to the version most of your customers will actually see, given how much local searching happens on a phone in a car park.

The order to check things in

If you are staring at a big gap right now, work through it in this sequence. It takes about twenty minutes and it will tell you whether this is an afternoon of work or a structural problem.

1. Confirm you are comparing lab to lab and field to field. Half of these investigations end here.
2. Look at which metric moved. CLS gaps are layout and design. LCP and INP gaps are weight and processing.
3. Run Lighthouse on both form factors and compare what each one downloads. If the phone run is pulling the same image bytes as the desktop run, you are serving desktop-sized assets to phones.
4. Sort third parties by main-thread blocking time and see whether one vendor is carrying the blame.
5. Only then look at your own JavaScript bundle.

Most sites resolve at step three or four. The ones that do not — where the images are already right, the third parties are lean, and the page is still slow on a phone because the platform ships a heavy runtime you cannot remove — are the ones where the ceiling is structural. That distinction is worth being honest about before spending anything, and we have laid out where it sits in what you can fix without rebuilding.

Either way, the starting point is knowing which of the four causes you have. Paste your address into our free audit and you will get a phone score and a desktop score side by side, with Core Web Vitals for each, plus page weight and crawl readiness for the site, in about thirty seconds. If the two scores are close, your mobile problem is smaller than it feels. If they are far apart, the audit will tell you which direction to start digging.