Why Is My Website Slow on Mobile Only?

Why the desktop test lies

A modern laptop has a fast processor, a large cache, and, usually, an office or home connection. A mid-range phone has roughly a quarter of the single-core performance, less memory, and a mobile network with high latency and variable bandwidth. A page that takes 800 milliseconds of JavaScript to become interactive on a laptop takes three to four seconds on that phone, before the network is even counted.

Google's Core Web Vitals data and its ranking signals are mobile-first. The number you see on your own screen is the least representative one available.

The four things that hurt phones specifically

1. Images sized for desktop. A 2,400-pixel hero image at 400 KB is an inconvenience on a laptop and a disaster on a phone that will display it 390 pixels wide. If the site serves one image size to every device, phones download six times the pixels they can show, and the Largest Contentful Paint waits for all of them. This is the single most common cause, and the fix is responsive images: srcset with several widths, the sizes attribute so the browser picks the right one, modern formats, and loading="lazy" on everything below the fold. Optimising images properly is a one-time job that fixes most mobile-only slowness by itself.

2. JavaScript the phone has to run. Downloading a script is a network cost; parsing and executing it is a CPU cost, and CPU is where phones fall furthest behind. A framework bundle, three analytics tags, a chat widget, a consent manager and a carousel add up to a megabyte of JavaScript that a laptop chews through and a phone chokes on. Symptoms: the page looks loaded but does not respond to taps for seconds; Lighthouse reports high Total Blocking Time and poor Interaction to Next Paint. The fix is less JavaScript: remove what is not earning its place, defer what is not needed immediately, and load third-party widgets on interaction rather than on page load.

3. Fonts that block text. Web fonts are often loaded in a way that leaves text invisible until the font arrives. On a fast connection that is imperceptible; on mobile it is a blank page for a second or two. font-display: swap or optional, preloading the one font file the first screen uses, and subsetting to the characters actually needed all help. The details are in our piece on web font performance.

4. Layout that reflows. Content that jumps as images, ads and embeds load is scored as Cumulative Layout Shift and is worse on small screens, where a shift of 200 pixels moves the thing you were about to tap out from under your thumb. Reserve space with explicit width and height on images and embeds.

Finding which one it is

Run Lighthouse (in Chrome's developer tools) in mobile mode, which simulates a mid-range phone with a throttled CPU and a slow 4G connection. Then run it in desktop mode. The gap is your answer:

• If mobile LCP is much worse and the LCP element is an image, it is images.
• If Total Blocking Time and INP are much worse, it is JavaScript.
• If there is a period where text is invisible, it is fonts.
• If CLS is high, it is layout.

Then check the field data. Search Console's Core Web Vitals report and PageSpeed Insights both show what real visitors on real phones experienced over the last 28 days, and that is the number Google uses. Lab tests tell you what to fix; field data tells you whether it worked.

A note on third-party scripts

The scripts you did not write are frequently the worst offenders, because nobody on your side measured them. A chat widget alone can add 300 KB of JavaScript; a tag manager with a dozen tags inside it can double a page's execution time. Audit them by loading the page with each one disabled in turn, and be willing to remove the ones nobody can name a use for.

Things people suspect that usually are not it

The hosting. Server response time is the same for every device. If time-to-first-byte is bad, it is bad on desktop too. Hosting rarely explains a mobile-only gap.

The mobile network alone. It contributes, but a well-built page is usable on slow 4G. If the page is only usable on wifi, the page is the problem.

"Mobile optimisation" as a separate product. There is no mobile version to optimise; it is one site. The optimisation is the same work, measured on the device that matters.

The order to do it in

Images first, because the fix is mechanical and the gain is largest. JavaScript second, because it is where the CPU gap lives. Fonts third. Layout shifts as you go. Re-test in mobile mode after each, and expect the field data to catch up over the following month.

Most sites that come to us with this complaint are fixed by the first two steps. If yours is not, or you would like someone to find the specific script or image that is doing it, book a call and we will run the diagnosis together.

Common questions