Why Your Website Is Slow on Mobile Data (and How to Fix It)
Your site loads instantly in the office and takes nine seconds for a customer on 3G. The causes are usually the same four things.
· 2 min read · Web Dev
In short: Most Pakistani visitors arrive on a mid-range Android phone over mobile data, not on the office wifi where the site was built and tested. That gap is why a site that feels fine to you loses customers before it renders.
Test it the way your customers see it
Open your site on your phone, on mobile data, away from the office. Then run it through Google PageSpeed Insights and read the mobile score, not the desktop one. The gap between the two is usually the whole problem.
Cause one: the images
This is the biggest cause by a wide margin, and the easiest to fix. Photos uploaded straight from a camera or a designer are often several megabytes each; on a page with six of them, that is most of your load time.
- Export at the size they actually display. A 4,000-pixel-wide photo in a 600-pixel slot wastes 85% of what was downloaded.
- Use WebP. It typically cuts file size by half or better with no visible difference.
- Add `loading="lazy"` to anything below the fold so it downloads only if the visitor scrolls.
On this site, converting the portfolio screenshots took the build from 245 MB to under 30 MB. Nothing about how it looks changed.
Cause two: too much JavaScript
Every script has to download, parse and run before the page becomes usable — and on a mid-range phone, parsing is far slower than downloading. Chat widgets, analytics, A/B testing tools and social embeds each add to this, and they accumulate without anyone deciding to.
Audit what is loading. Remove what nobody looks at. Load the rest after the page is usable rather than before.
Cause three: fonts
Custom fonts commonly block text from appearing until they download — so the visitor sees a blank page while the font arrives. Load no more than two weights, use `display=swap` so text shows immediately in a fallback, and preconnect to the font host.
Cause four: no caching
Without cache headers, a returning visitor downloads everything again. Build files with a hash in their name can be cached for a year safely, because a change produces a new filename. The HTML must never be cached, or visitors keep seeing the old site after you deploy — a mistake that looks exactly like "my changes did not go live".
What good looks like
Largest Contentful Paint under 2.5 seconds on mobile. Total page weight under about 1 MB for a content page. No layout shift as images load — set width and height so space is reserved.
This is worth real money: speed is a ranking factor, and a visitor who waits nine seconds mostly does not wait.
We do website development with mobile performance as a requirement rather than a later optimisation. If your site feels slow and you are not sure why, send us the address and we will tell you what is causing it.