Why is my mobile performance score worse than my desktop score?

The desktop profile assumes a fast wired connection with low latency and an unthrottled processor.

The mobile profile assumes a slow mobile connection with a round trip of around 150 milliseconds and a processor slowed about four times.

The mobile viewport is also narrow, so different images, layouts and sometimes different scripts are served.

Scores are then mapped from the measured timings through thresholds that differ between the two profiles.

So the two numbers are not the same page measured twice; they are the same page under two deliberately different assumptions.

Downloading a script depends on the network; parsing, compiling and executing it depends on the processor.

A slowed processor multiplies every long task, which is what total blocking time and interaction delay measure.

A script bundle that takes a few hundred milliseconds on a desktop can take a second or more under mobile throttling.

Network improvements — compression, caching, a CDN — do little for this part, which is why they often fail to close the gap.

Reducing the script that runs before the page is usable is what moves the mobile score most.

Images served at desktop sizes to a narrow viewport, because responsive candidates or the sizes attribute are missing.

The largest element on mobile being a different element — often a hero image that is lazy-loaded or discovered late.

Layout shifts caused by elements that reflow differently at narrow widths, such as banners and embeds.

Third-party scripts whose cost is small on a desktop processor and significant on a throttled one.

Fonts and render-blocking stylesheets, whose latency cost is multiplied by the slower round trip.

Real-user data is grouped by device type, and for most sites mobile visitors really do have slower devices and networks.

If field data for mobile is good, a poor laboratory score is a warning to watch rather than an emergency.

If field data for mobile is also poor, the laboratory result is describing a real experience.

Search engines use the field data rather than the laboratory score, so it is the one that decides what counts.

Where there is not enough traffic for field data, the laboratory mobile profile is the best available proxy.

Measure how much JavaScript runs before the page is interactive, and defer or remove what is not needed for the first view.

Check that the largest element on the mobile layout is loaded eagerly and discovered early.

Serve images sized for the mobile viewport, with correct responsive candidates.

Reserve space for anything that loads late so the mobile layout does not shift.

Then re-measure under the same profile several times, since single runs vary.

Work tested only on a fast development machine is effectively tested against the desktop profile, so script-heavy changes pass review without anyone feeling their mobile cost.

Adding a feature as a client-side component shifts work from the network to the processor, which the desktop score barely registers and the mobile score punishes.

Measuring each change with the mobile profile as well, or with the processor throttled in developer tools, catches this before release rather than after.

A performance budget expressed in script size is the simplest guard, because it limits the one cost the two profiles disagree on most.