Why your app is slow on Nigerian networks and what to do about it

Developers test on office broadband and the fastest phone in the building. Customers use a mid-range Android, with half its storage full, on a cell tower shared with half the street. The gap between those two experiences is where apps go to die.

Latency, not bandwidth

When people say the network is slow, they usually mean bandwidth: how much data arrives each second. On mobile networks the bigger problem is often latency: how long each request takes to make the round trip. If your servers are on another continent, every round trip crosses an ocean and back.

A typical web page or app screen does not make one request. It makes dozens: the page, the styles, the scripts, the fonts, the images, the data. Many of them wait for the one before. Multiply a long round trip by thirty dependent requests and you have a screen that takes ten seconds to appear on a connection that could download the whole thing in two.

Your customers also pay for every megabyte. A heavy app is not only slow; it costs them data, and they notice.

First, measure what your customers see

Before changing anything, find out how bad it is:

• Use a real mid-range Android phone, not a flagship, on a mobile connection, with the browser cache cleared.
• Time the moments that matter: when something useful appears, and when the customer can actually tap and act.
• Run Google’s PageSpeed Insights on your key pages. Where it has enough traffic, it shows field data from real visitors, which is more honest than any lab test.
• Check the total size of the page or app. Everything you send, the customer pays for.

Most teams are surprised the first time. The surprise is useful: it turns “the app feels slow” into a number you can improve and track.

Six changes that make the biggest difference

1. Ship less JavaScript

Scripts are the most expensive thing you send. They must download, and then a modest phone processor has to work through them before the screen responds. Remove libraries you barely use, load features only when they are needed, and question every third-party script for chat widgets, analytics and trackers. Each one costs your customers time.

2. Shrink every image

Images are usually the largest part of the download. Use modern formats such as WebP or AVIF, serve sizes that match the screen rather than a 4,000-pixel photo shrunk by the browser, and lazy-load anything below the first screen. This one change often halves the weight of a page.

3. Serve from close to your users

Put your static files on a content delivery network with locations in or near West Africa, and think carefully about where your servers and database sit. Moving closer to your customers cuts the cost of every round trip.

4. Cache aggressively

A returning customer should not download your logo, fonts and scripts again. Set long cache lifetimes on files that rarely change. For web apps, a service worker can keep the core of the app on the phone, so it opens instantly even on a poor connection.

5. Make the first screen useful immediately

Send something meaningful in the first response rather than a blank page that assembles itself after several more requests. Rendering the page on the server and keeping the first screen light means the customer sees something, and can act on it, while the rest loads.

6. Design for the request that fails

On a mobile network, some requests will fail. A good app expects it: it retries sensibly, tells the customer what happened, keeps what they typed and lets them carry on. For anything involving money, make sure a retried payment cannot charge the customer twice. A double charge caused by a dropped connection is one of the fastest ways to lose a customer’s trust.

Native apps have the same problem, plus storage

If you ship an Android app, its download size matters as much as the network. Many customers are always one app away from a full phone, and a large app is the first thing they delete. Keep the install small, and consider whether a progressive web app, which installs from the browser and takes up very little space, would serve them better.

Make speed part of the agreement

None of this is exotic. It is discipline, applied before launch rather than after the complaints start. The simplest way to make it stick is to write it down: agree a performance budget at the start of the project, such as a maximum page weight and a time to first useful screen on a mid-range phone, and test against it at every demo, like any other feature.