Why your mobile Lighthouse score is lower than desktop

Your mobile Lighthouse score is lower than desktop because the two are different tests. Mobile simulates a mid-range phone on a slow 4G connection with the CPU slowed down 4 times, while desktop simulates a fast connection with no CPU slowdown. The same page has to do the same work under much tighter limits on mobile, so it scores lower, often by a wide margin.

Mobile and desktop are two different tests

Lighthouse does not take one measurement and adjust it for screen size. It runs two separate tests with different device profiles, and each has its own scoring.

	Mobile	Desktop
Throttling method	Simulated	Simulated
Network	Slow 4G profile: about 150 ms round trip, 1.6 Mbps down, 750 Kbps up	Much faster: about 40 ms round trip, around 10 Mbps
CPU	4x slowdown	No slowdown
Viewport	Narrow phone screen, about 412 px wide, high pixel density	Wide desktop window, about 1350 px wide
Scoring curves	Mobile curves	Separate, stricter desktop curves

PageSpeed Insights, Chrome DevTools and the CLI all use these profiles by default. In DevTools you pick Mobile or Desktop in the Lighthouse panel; with the CLI, mobile is the default and desktop needs the desktop preset.

Because the scoring is different, a mobile 70 and a desktop 70 do not describe the same page speed. Treat them as two separate results.

The CPU slowdown makes JavaScript expensive

The biggest single reason for the gap is the 4 times CPU slowdown. Every script that is downloaded has to be parsed, compiled and run, and on the simulated phone that work takes 4 times as long as on the unthrottled machine.

That shows up in Total Blocking Time, which adds up how long the main thread was blocked by long tasks during load. A task that takes 40 ms on desktop is not a long task at all. Slowed down 4 times, it becomes 160 ms, of which 110 ms counts as blocking. Multiply that across a framework bundle, a tag manager, analytics, a chat widget and a consent tool, and mobile TBT can be many times higher than desktop.

TBT carries 30% of the performance score, the largest single weight, so this one metric often explains most of the difference. For a step-by-step view of the weights, see how the Lighthouse performance score is calculated.

The slow network punishes large files

The second cause is the simulated slow 4G connection. With 1.6 Mbps of download bandwidth and 150 ms of latency per round trip, large files and long chains of requests add real seconds.

This mainly affects:

• Largest Contentful Paint. If the LCP element is a 600 KB hero image, it takes a noticeable time to arrive on slow 4G, even if it appears almost instantly on desktop.
• First Contentful Paint. Render-blocking CSS, web fonts and synchronous scripts in the head all have to arrive before anything is painted.
• Request chains. A font referenced from CSS that is loaded by a script costs several round trips, and each round trip is far slower on the mobile profile.

For example, a blog template that loads a 1.8 MB hero image, three font files and a large stylesheet might paint quickly on desktop and still take several seconds to show its main image on mobile.

Viewport and image sizes change what loads

The small, high-density phone screen changes the page itself, not just its speed.

• A different LCP element. On desktop, the largest element might be a hero image. On a narrow phone, it might be a heading, a product photo lower in the layout, or even a cookie banner that covers most of the screen.
• Different image downloads. With responsive images (srcset and sizes), the browser picks a file based on the viewport width and pixel density. If the sizes attribute is missing or wrong, the phone may download a desktop-sized image anyway.
• Mobile-only layout. Sticky headers, hamburger menus, app install prompts and collapsed sections often only appear on small screens, and they can add scripts or cause layout shifts that desktop never sees.

So when you compare mobile and desktop, check which element Lighthouse reports as the LCP element in each run. It may not be the same one.

Find which metric explains the gap

The overall scores tell you that mobile is slower, but the five metrics tell you why. Put the mobile and desktop reports side by side and compare each metric rather than the headline number.

• TBT much higher on mobile, LCP similar: the gap is mostly JavaScript. Look at the main-thread work and third-party script diagnostics.
• LCP and FCP much higher on mobile, TBT similar: the gap is mostly bytes and round trips. Look at image sizes, fonts and render-blocking requests.
• CLS worse on mobile only: something in the mobile layout moves. Look at banners, sticky elements and images without dimensions.
• Everything slower by a similar amount: check server response time first, because a slow first byte delays every metric.

This takes a minute per page and tells you where to start, instead of guessing from the score alone.

Desktop is not always the easier test

Desktop uses its own scoring curves, and they are stricter in absolute terms. Because desktop has more resources, Lighthouse expects faster times before it awards a good metric score. The same LCP time can earn a high score on mobile and a lower one on desktop.

In practice, desktop scores are usually higher anyway because the throttling difference is so large. But if your desktop layout loads heavier images or extra content, desktop can occasionally score lower than mobile, and that is not an error.

Which score matters for Google

Mobile is the one to prioritize, for two reasons.

1. Mobile-first indexing. Google mainly uses the mobile version of your content for indexing and ranking. If your mobile pages are slow or broken, that is the version Google evaluates.
2. Core Web Vitals are assessed per device type. Google’s page experience signals use real-user field data from the Chrome UX Report, which reports mobile and desktop visits separately. Search Console’s Core Web Vitals report also shows mobile and desktop as separate groups.

Keep in mind that the Lighthouse score itself is not a ranking factor. Lighthouse is a lab diagnostic tool; Google uses field data for page experience. A low mobile lab score is still a useful warning, because it shows where real visitors on slower phones are likely to struggle. Our post on lab data vs field data explains how the two relate.

What to fix first on mobile

Start with the changes that move the heaviest-weighted metrics, and make them in the templates that serve the most pages.

1. Reduce JavaScript on the main thread. Remove unused scripts, defer non-critical ones, delay chat widgets and marketing tags until after load, and split large bundles. This lowers TBT, the biggest share of the score.
2. Make the LCP element fast. Serve a correctly sized, modern-format image, do not lazy-load the LCP image, and give it high fetch priority so the browser requests it early.
3. Reserve space for everything that loads late. Set width and height on images and embeds, and reserve room for ads and banners to keep CLS low.
4. Cut render-blocking resources. Inline critical CSS, load fonts efficiently and avoid synchronous scripts in the head to improve FCP.
5. Check server response time. A slow first byte delays every other metric, and its impact grows on the high-latency mobile profile.

If the LCP image is your main problem, our guide to improving LCP on blog and product pages goes deeper.

How to check this across your whole site

The manual way is to run Lighthouse twice for every URL, once with the mobile profile and once with the desktop preset, and keep both reports. You can do this with the CLI or the PageSpeed Insights API by looping over your sitemap, but it doubles the number of runs and reports to manage, and Lighthouse still only tests one page per run, as we cover in Lighthouse only tests one page.

AiroPages runs every page on both mobile and desktop as part of each URL scan, using PageSpeed Insights settings, and groups issues by template so you can see which mobile problems affect the most pages.

Fix mobile first

A lower mobile score is expected: the test is deliberately harder, with a slow network, a slowed CPU and a small screen. Focus on mobile because that is the version Google indexes first and the one where slow pages hurt most. Cut main-thread JavaScript, speed up the LCP element and stop layout shifts, and both scores will rise together.