How to Fix a Website That Is Fast on Your Laptop but Slow on Phones

Your website feels instant on your laptop, then a customer opens it on a phone and waits. The page loads in pieces, the button ignores the first tap, and the text jumps as they try to read it. Your laptop and their phone are not the same test, hardware or network. This post shows you how to reproduce the slow version, find which part is failing, and fix it in the order that helps phones most.

Why your laptop is lying to you

On your laptop you are testing the best case: a fast processor, strong WiFi, a warm browser cache, and full power. A phone visitor has none of that. They are usually on a mid-range Android phone, on a mobile network that comes and goes, with other apps competing for memory.

Speed tools copy those harder conditions on purpose. In a Lighthouse mobile test, the network is throttled to a slow 4G profile, around 1.6 Mbps download with high latency, and the processor is slowed to about a quarter speed. The desktop test applies little or no throttling. That is why the same page can score in the 90s on desktop and in the 40s on mobile. The mobile score is not a bug in the test. It is the honest one.

JavaScript is where the gap opens widest. Code that runs in a blink on a laptop must be downloaded, parsed and executed by a much slower phone processor. Images hurt too. A hero image sized for a monitor may be several times larger than a phone screen needs, but the phone still downloads every byte, then spends power shrinking it to fit.

Step 1: Reproduce the problem the right way

Do not start by guessing. Run your homepage and your most important landing page through our Website Speed Test and read the mobile result first, not the desktop one.

Then look at the three Core Web Vitals. Largest Contentful Paint, or LCP, is when the main content appears, and good is 2.5 seconds or less. Interaction to Next Paint, or INP, is how quickly the page responds after a tap or click, and good is 200 milliseconds or less. Cumulative Layout Shift, or CLS, is how much the page moves while loading, and good is 0.1 or less. Google judges these on real visits over 28 days, at the 75th percentile, so one fast run proves very little.

Write down which of the three fails worst on mobile. That number decides your fix order. A bad LCP is a loading problem. A bad INP is a JavaScript problem. A bad CLS is a layout problem. For a site that is slow everywhere, not just on phones, work through How to Fix a Slow Website after this one.

Step 2: Fix the hero and the images first

On most phone-slow pages, the largest thing in view is an oversized image. Check three things. First, size: serve a smaller version to small screens with responsive image sizes. Second, format: use WebP or AVIF where you can, and compress hard. Third, priority: the hero image should load early and should not be lazy loaded, while images below the fold should be lazy loaded so they do not compete with it.

Also give every image and video a width and height, or a fixed aspect ratio box. Without them, the browser moves everything when the image arrives, which directly causes layout shift, covered again in Step 4.

Step 3: Cut the JavaScript a phone has to chew through

If your INP is poor, or the test reports long tasks and high blocking time on mobile only, the page asks the phone processor to do too much. Look at what loads before the page becomes usable: sliders, chat widgets, popups, video players, ad scripts, analytics tags and page builder animations are the usual stack.

Ask three questions of each one. Can it be removed? An old tracker or a chat tool nobody answers is pure cost. Can it load later? Anything not needed for the first screen should be deferred until the main content is interactive. Can it load only when needed? A map or video can load when the visitor scrolls to it, not on arrival.

Be strict here. A fast desktop processor hides this problem. A phone cannot. Every script you defer or delete returns time to every tap for the whole visit.

Step 4: Stop the page jumping around on a small screen

CLS problems feel worse on phones because the screen is small. One late banner, font swap or cookie bar can push the button a visitor is about to tap out from under their thumb. The fix is to reserve space for everything that loads late: images, videos, embeds, ads and banners all need a box with a set height or aspect ratio before they load.

Fonts deserve a check too. If text reflows when the real font arrives, use font display settings that swap quickly and match the fallback spacing closely where you can. Then test on a real phone. A throttled test plus one real device catches almost every shift a visitor would hit.

Step 5: Check the phone-only problems you cannot see on desktop

Some faults only exist in the mobile version. Open the site on your phone, on mobile data with WiFi off, and tap through the customer journey: landing page, main button, form, checkout or contact step. Watch for a mobile plugin that loads extra files, autoplay video, popups that cover the whole screen, and tap targets that are too small or too close together.

Also check for extra redirects on the phone version, such as a hop to a mobile subdomain and back. Each one adds a full round trip before anything useful loads. If the report flags redirect chains or a slow server response, fix that first.

What to do first

Start today, in this order. First, run the Website Speed Test on mobile and note which of LCP, INP or CLS fails worst. Second, fix that one thing only: shrink and prioritise the hero image for a bad LCP, defer or remove non-essential scripts for a bad INP, or reserve space for late-loading elements for a bad CLS. Third, retest on mobile and confirm the number moved. Then do one real-phone check on mobile data before you call it done.

Ignore the desktop score while you work. Once the mobile numbers pass, the desktop numbers will take care of themselves, and so will the customers who never told you the site was slow. They just left.