This is a conversation we have several times a month. A client calls: their site is hosted with a major European provider, the plan is decent, the server is powerful — and yet customers in Lomé, Cotonou or Abidjan complain about slowness. On the manager's own computer, everything seems fine.
The culprit is almost never the server. It is distance.
What a round trip costs
Every time a browser asks a server for something, the request must physically cross the network and come back. From Lomé to a data centre in Paris, expect 120 to 180 milliseconds per round trip in good conditions. To Frankfurt or Amsterdam, often more.
One hundred and fifty milliseconds is nothing. The problem is that a web page never makes a single round trip. It chains dozens: DNS resolution, TLS handshake, HTML document, stylesheets, scripts, fonts, images, API calls. With thirty sequential requests, those 150 ms become several seconds of waiting — and server power has no influence on any of it.
Why mobile makes it worse
In West Africa, most web traffic is mobile. A mobile connection adds its own latency on top of the long-distance one: radio link setup time, quality variations depending on coverage, and packet loss that triggers retransmissions.
The result: a site that renders in 1.2 seconds on Parisian fibre can take 6 to 8 seconds on a phone in Kara. Same page, same server.
Four levers, in order of effectiveness
1. Move static files closer. Images, stylesheets, scripts and fonts account for most of a page's weight. Serving them from a delivery network with points of presence in Africa — or at least in southern Europe — removes most long-distance round trips.
2. Reduce the number of requests. Every file removed is a round trip saved. Bundling scripts, dropping unused fonts and libraries loaded "just in case" often yields more than doubling server power.
3. Serve images in the right format and size. A 2000-pixel-wide photo sent to a 390-pixel phone wastes 90% of the data. Modern formats such as AVIF and WebP cut weight by a further three to five times at equivalent quality.
4. Consider regional hosting. For an application where every interaction triggers a server call — a management system, a point of sale, a back office — moving the server closer to its users becomes the only genuinely decisive lever.
Measure before deciding
Before committing to any work, measure from where your users actually are, not from your office. A speed test run from a fibre-connected browser in Lomé says nothing about a customer's experience on a phone in Sokodé.
Measurement tools let you choose the test location: use it. And always compare two numbers — the time to first useful content, and the time before the page becomes genuinely usable. The second one determines whether a visitor stays or leaves.
What we see in practice
On the migrations we handle, combining a delivery network, image optimisation and fewer requests typically cuts perceived load time by a factor of three — without changing a line of application code or increasing the hosting bill.
Changing servers comes last, if at all. It is the most expensive lever, and rarely the most effective.