Why is my site slow on phones but fast on a computer?

What the data says

These are the Almanac's figures for whole sites, from real visitors unless marked lab. A site counts as good on a metric when at least three in four of its visits meet the mark.

Mobile trails on every row except layout stability, where it does a little better. The Almanac ties the loading gap to slower networks and less capable devices. It adds that on mobile, slower devices and less stable networks tend to amplify the effects of page complexity and limited optimization. See web speed benchmarks from 2025 for the full set.

Reason 1: the processor

A phone's processor is slower than a laptop's, and a page's JavaScript runs on it. Lighthouse's mobile test slows the test machine's processor four times to stand in for a mid-range phone. The browser has to download the code, parse and compile it, and run it, and the running happens on the main thread, which is also the thread that responds to taps. A script that is quick on a laptop can keep a phone busy for longer. That is why the biggest relative gap in the table is the lab number for blocking time, and why Interaction to Next Paint, which depends on the main thread, shows the widest gap between desktop and phone: 20 points.

Signs: a poor Interaction to Next Paint or a high Total Blocking Time on mobile only, a page that paints but ignores taps for a moment, and heavy third-party tags. See reduce main-thread work, break up long tasks and third-party scripts.

Reason 2: the network

A phone connection is often slower and less steady than a wired or Wi-Fi one. Each new connection costs round trips, and a round trip over a weak signal takes much longer. Every extra host, every redirect and every large file hurts more. See DNS, TLS and connections and speed for visitors on slow networks.

Signs: a slow Time to First Byte or First Contentful Paint on mobile only, many hosts in the Network panel, and big files that nobody needs on a phone.

Reason 3: the page is not the same

A phone shows a different page, even when the address is the same.

• The main element can change. In the Almanac, an image was the Largest Contentful Paint element on 85.3% of desktop pages and 76% of mobile pages. Text was the element on 14.4% of desktop pages and 23.7% of mobile pages. A desktop hero image may not be the thing a phone waits for.
• The image can be the wrong size. Without srcset and sizes, a phone may download the desktop version. See responsive images.
• Some things appear only on phones: cookie notices, sticky bars, app banners and chat buttons. They can add weight and move the page. See how to fix CLS.
• Some things may only look hidden. Check, in the Network panel on a phone-sized window, whether the files for elements you hide with CSS are still downloaded.

Reason 4: the test

A test labelled "mobile" is a simulation. Lighthouse and PageSpeed Insights run on a server, with a slowed processor and a limited network that they calculate, not a phone. A resized desktop browser shrinks the window and nothing else. Both are useful, and neither is a phone. See testing on real phones.

The opposite problem is common too. A desktop test on a fast machine can look excellent and say nothing about the phone. Always read the mobile tab, and in the real-visitor section, look at mobile and desktop separately. The Core Web Vitals are judged for each device on its own.

How to find your cause

1. Compare the real-visitor numbers. In PageSpeed Insights, read the mobile and desktop tabs. Note which of the three metrics differs most.
2. Slow the processor and the network in your own browser. In Chrome DevTools, open the Performance panel, set CPU throttling and a slow network, and record the load. See the Performance panel guide.
3. Look for long tasks. They show as red-cornered blocks of 50 milliseconds or more. Open one to see which script it is.
4. Read the Network panel on the same slow settings. Note the total bytes, the largest files and the number of hosts. See the Network panel guide.
5. Check the main element on a phone-sized window. Find out what Largest Contentful Paint is there, because it may not be the same element.
6. Try a real phone, on mobile data, with an empty cache.

What to fix, by cause

Mistakes to avoid

• Judging the site by the desktop score. The mobile tab is the test that counts for most visitors.
• Testing "mobile" by shrinking the window. It does not slow the processor or the network.
• Hiding desktop features with CSS instead of not loading them on a phone.
• Optimizing only for the lab mobile score. The real-visitor data decides whether the page passes.
• Looking only at the home page. Other pages can differ, and the Almanac found that secondary pages pass more often than home pages.

Check your own page

Run the free audit and read the mobile results first. If the real-visitor section passes on desktop and fails on mobile, find the failing metric in the table above and start with the guide on its row.

Sources

• Performance chapter, Web Almanac 2025: the desktop and mobile figures, the largest-element types, the remarks on slower devices and networks, and the Total Blocking Time medians.
• Lighthouse and the Lighthouse guide on this site: how the mobile test is simulated.
• The guides linked above, which carry the sources for the fixes.