A site that opens instantly on the laptop it was built on can be close to unusable on a phone on mobile data. Nothing is broken. The site is simply being judged by a different machine on a different connection, and it was never tested there.
This is what actually makes that difference, roughly in order of how much it matters.
Images, and it is not close
On most sites, images are the majority of what gets downloaded. A photograph straight off a phone or a camera can be several megabytes. Dropped into a page and displayed at a quarter of its size, every one of those bytes still travels down the wire first.
Three things fix nearly all of it:
- Serve the size that is actually displayed. A picture drawn 400 pixels wide should not arrive 4,000 pixels wide.
- Serve a modern format. AVIF and WebP are typically far smaller than JPEG and PNG at the same visible quality, and browsers that cannot read them can be sent the old format automatically.
- Do not load what has not been reached. Images below the fold can wait until the reader scrolls toward them.
The trap is that all of this is invisible on a fast connection. The page looks identical. Only the bill and the waiting change.
What that weight costs a Nigerian visitor
This is the part that rarely gets said out loud: on prepaid mobile data, page weight is money. A visitor on a metered bundle pays, in cash, for every megabyte a page decides to send them. A heavy homepage is not just slow. It is a page that charges people to look at it.
It is worth working out your own number once. Take your homepage's total weight, multiply by what a gigabyte costs on a common local bundle, and you have the price of a single visit. Most people are surprised, and most people fix their images that afternoon.
Fonts
Custom fonts are downloaded before text can be drawn in them. Loaded carelessly, they produce either a blank space where the words should be or a flash of one typeface replaced by another. Either way the reader is waiting on a decoration.
- Load only the weights you actually use. Four weights of one family is often three more than the design needs.
- Host them yourself rather than fetching from a third party, which removes a DNS lookup and a connection to somebody else's server.
- Tell the browser to show the text immediately in a fallback and swap when the font arrives, so words are never invisible.
Third-party scripts
Chat widgets, analytics, heat maps, cookie banners, ad pixels, review badges. Each one is a request to a server you do not control, running code you did not write, on the same thread that is trying to draw your page. They are also the part of a site that grows quietly: nobody ever removes one.
Two habits help. Audit them once a year and delete what nobody reads. And where something is genuinely wanted but not urgent (a chat widget, for instance), load it when the visitor reaches for it rather than on arrival, so the people who never use it never pay for it.
The thing that annoys people most is not slowness
It is movement. You go to tap a link, an image finishes loading above it, the page jumps, and you tap an advert instead. That is a layout shift, and it happens whenever something arrives without its space being reserved in advance.
The fix is unglamorous: every image gets its dimensions declared so the gap exists before the picture does; anything that loads late (a banner, an embed, a font swap) is given its final height up front. It costs nothing and it is the single most noticeable improvement a slow site can make.
How to measure it honestly
Testing on your own laptop on office wifi tells you almost nothing about the visitor you are worried about. Three ways to get a real answer:
- Run PageSpeed Insights on the live URL and read the MOBILE tab. The three numbers that matter are how long the largest thing takes to appear, how much the page moves while loading, and how long it is unresponsive to taps.
- In your browser's developer tools, throttle the network and the processor together. A phone is not just a slower connection, it is a slower computer, and testing only the network hides half the problem.
- Open the site on an actual mid-range Android phone on mobile data, away from the office. Nothing substitutes for this.
The order to fix things in
Most sites do not need a rebuild. They need four afternoons, in this order:
- Resize and re-encode every image, and lazy-load the ones below the fold.
- Declare dimensions on everything so the page stops moving.
- Cut the third-party scripts nobody looks at, and defer the ones that can wait.
- Trim the fonts to what is used.
That sequence costs very little and usually accounts for most of the difference. If the site is still slow afterwards, the problem is architectural, and that is a genuinely different conversation. But it is worth being certain you are having it for the right reason.
