How to Make a Website Fast on Cameroonian Mobile Networks

How to Make a Website Fast on Cameroonian Mobile Networks#

Most websites are tested on a laptop, on office wifi, by someone sitting next to the router. Most websites are then used on a mid range Android phone, on mobile data, by someone standing outside a shop deciding whether to bother.

Those are different products. A site that feels instant in the first situation can be unusable in the second, and the person who leaves does not send you an email explaining why.

Almost everything that makes a site slow here is something you can see and fix. Here is what to look at, in the order that pays.

Key takeaways#

• Africa has the highest share of mobile web traffic of any region, so the phone is the primary device, not the fallback.
• Page weight is the problem far more often than server location or hosting plan.
• Images are usually more than half the weight of a slow page, and the easiest thing to fix.
• Test on a real mid range phone over mobile data, not on your laptop with the network throttled.
• Every second of delay costs you people who never tell you they left.

Build for the phone first, because that is what people use#

Mobile devices account for the large majority of web traffic across Africa, a higher share than any other region. In practice, if you are building for a Cameroonian audience, the phone is not a version of the site. It is the site.

That changes decisions. It means the design starts at 360 pixels wide and grows, rather than starting on a desktop canvas and being squeezed afterwards. It means tap targets sized for a thumb. It means the phone number is a link that dials, and the WhatsApp button is where a thumb already rests.

It also means the network is not the one in your office. Mobile data in Cameroon is usable and often good, but it is variable, and it gets worse exactly where business happens: inside buildings, in crowds, in traffic.

Images are more than half your problem#

If a page is slow, look at images before anything else. In nearly every slow site I open, they are the largest single cost and the fastest thing to fix.

Three things go wrong, usually together.

The file is enormous. A photograph from a phone camera is often three or four megabytes. Uploaded straight into a page, that is what every visitor downloads.

The dimensions are wrong. An image displayed 600 pixels wide but uploaded at 4000 pixels wide sends about forty times more data than the screen can use.

The format is old. PNG and JPEG are decades old. WebP typically produces the same visible quality at a fraction of the size.

The fix is unglamorous and it works. Resize each image to roughly the width it displays at, serve it as WebP with the original as a fallback, and let images below the first screen load only when the reader scrolls to them.

To put a number on it: on this site, the blog images were being served as PNG at about 2.9 MB across the listing page. The same images as WebP are about 708 KB. Nothing about how they look changed.

The rest of the weight, in the order worth attacking#

The pattern is the same throughout. Send less, send it later if it is not needed immediately, and never send anything twice. Google bundles the measurable part of this into Core Web Vitals, which feed into ranking.

Fonts deserve a specific note because they are easy to get wrong quietly. Every extra weight is another file. Loading four weights of two families is most of a megabyte before a word is readable. Two weights of one family covers almost any design, and setting the font to swap means text appears immediately in a fallback rather than leaving a blank space while the file downloads.

Test the way your customers browse#

This is the step almost everyone skips, and it is the one that changes decisions.

Testing on a laptop with the network throttled in developer tools is better than nothing, but it flatters the result. A real phone is slower at running JavaScript than a laptop pretending to be slow, and that gap is where the difference lives.

What I do:

• Open the site on an actual mid range Android phone, on mobile data, with wifi off.
• Do it away from the office, ideally somewhere with ordinary signal rather than excellent signal.
• Time it honestly. Count how long until you can read something, and how long until you can tap something.
• Run Google PageSpeed Insights and read the mobile score, not the desktop one. The desktop score is the flattering one and it is not the one your customers experience.

If it takes more than about three seconds before anything useful appears, you are losing people, and the ones you lose are the ones who were only mildly interested. Those are most of them.

What good looks like#

A small business site should comfortably come in under 1 MB for a first visit, with something readable on screen in the first second or two on a normal connection. That is achievable with real photographs and a proper design. It is not achievable with a page builder, four font families and an uncompressed hero image.

If your current site is a long way from that, the honest answer is often that fixing it costs a similar amount to rebuilding it, because the weight comes from how it was assembled rather than from anything you can switch off.

Conclusion#

Speed is not a feature you add at the end. It comes from choices made while building: how images are handled, how much code is shipped, how many fonts get loaded, and whether anyone ever opened the site on a phone over mobile data.

Fix the images first, because that is where the megabytes are. Then remove what you are not using. Then test on the phone your customers actually own, not the laptop you built it on.

If you want to know where the weight is on your current site, that is a quick thing for me to look at. I write more about the technical side in my SEO services for Cameroon, and there is more on how I build in web design in Buea.

Site feeling slow? Get in touch and I will tell you what is making it slow and whether it is worth fixing or rebuilding.