Why Is My Website Slow on Mobile? 7 Real Causes

Your website loads instantly on your laptop. On your phone, out in the world, it takes forever.

You're not imagining it. And your developer isn't lying when they say it's fast — they're testing on a fast machine, on office wifi, with the site already cached in their browser. That's not what your customers get.

Here's what's actually happening, in plain words.

First, test it properly

Before reading further, do this. It takes two minutes.

1. Open your site on your phone
2. Turn wifi off so you're on mobile data
3. Open a private or incognito tab, so nothing is cached
4. Count the seconds out loud until you can read the main heading

Under 2 seconds is good. Two to four is losing you people. Over four and most visitors never see your homepage at all.

Now, the causes.

1. The images are far too big

This is the number one cause, every time.

Someone exports a background photo at 4000 pixels wide because it looked crisp on a big monitor. Your phone downloads all 4000 pixels to display about 400 of them. You just made your visitor download something ten times larger than they needed.

A well-built homepage is under 1MB in total. Plenty of sites I look at are 5MB or more, and almost all of that is pictures.

The fix: serve smaller images to smaller screens, and use a modern format like WebP. This is a few hours of work, not a rebuild.

2. The fonts load late

Your text is ready before your fonts are. So the browser has a choice: show nothing, or show the text in a default font and swap it later.

Most sites show nothing. That's why you sometimes stare at a blank page that suddenly fills with words.

Every extra font weight — bold, light, italic — is another separate file. Three weights means three downloads, each one holding your text hostage.

The fix: use fewer weights, host the fonts yourself instead of fetching them from Google's servers, and tell the browser to load them early.

3. The page is built in the visitor's browser

This one is invisible but it matters more than the rest.

Some websites arrive as an empty shell. The shell then asks the server "what should I say?" and waits for an answer before showing anything.

On fast wifi, you see a brief flash. On mobile data in a lift, you see a white screen and assume the site is broken.

The alternative is to prepare the pages in advance, so the server hands over a finished page. Same content, but it arrives ready to read.

The fix: this is architectural, so it's a bigger job — but it's usually the change that makes the biggest difference.

4. Too much code, most of it unused

Someone needed a date picker, so they installed a library. The library brought five other libraries. Now every visitor downloads all of it, on every page, whether the date picker is on that page or not.

Template sites are the worst for this, because the template includes everything the author thought anyone might want.

The fix: remove what isn't used, and split the rest so each page only loads what it needs.

5. Third-party scripts

Analytics. Chat widget. Heatmap tool. Two ad pixels. A review widget. A cookie banner.

Each one is a request to somebody else's server. If their server is slow today, your site is slow today, and there's nothing you can do about it.

I've seen sites where the actual website loads in under a second and takes four seconds more waiting on other people's code.

The fix: list every third-party script and ask what each one earns you. Most sites can drop half of them and lose nothing.

6. Nothing has been updated in years

Old code isn't just a security problem. Frameworks get faster with each version — better compression, smaller output, smarter loading.

A site on a four-year-old setup is missing four years of free performance improvements.

The fix: update carefully, test, update again. Dull work, real payoff. On one rebuild, clearing out old dependencies and console errors alone moved the Lighthouse "Best Practices" score 29 points.

7. The server is far away, or just slow

If your server is in Virginia and your customer is in Dublin, every request crosses an ocean. Add cheap shared hosting that's serving four hundred other sites, and the delay stacks up before the page even starts loading.

The fix: a CDN, which stores copies of your site near your visitors. Often the single cheapest improvement available.

What this actually costs you

Here's arithmetic you can run on your own numbers.

Take your monthly visitors — say 10,000. Research consistently shows mobile visitors dropping off sharply past two seconds; call it a conservative 10%. That's 1,000 people a month who wanted what you sell and left before seeing it.

Now apply your conversion rate — say 2% — and your average order value. At $200, those lost visitors are $4,000 a month. $48,000 a year.

Put your own figures in. Whatever comes out is what a slow site costs you, quietly, every month, while it looks fine on the office wifi.

The good news

Almost none of this requires a redesign.

Causes 1, 2, 4, 5 and 7 are usually a few days of work by someone who knows where to look. Cause 3 is bigger. Cause 6 is dull but straightforward.

If someone has quoted you for a full rebuild because your site is slow, get a second opinion first. You may be paying five figures to solve a problem worth three.

---

Want to know which of these seven is hurting your site? Send me the URL and I'll tell you what I find.