For years African websites were served from Frankfurt or Virginia, quietly adding up to 200 ms to every single click. The good news: most of that is recoverable, and the fixes follow a clear order of impact. Work down this list and stop when the numbers are good enough.
Why latency matters more than you think
Latency is paid on every round trip, and modern pages make a lot of them: DNS, TLS, the HTML, then dozens of assets and API calls. If each round trip crosses an ocean, even a fast back end feels slow. Worse, the effects compound — a 170 ms origin can turn a page that should load in half a second into a two-second wait. Faster sites convert better, rank better and bounce less, so this is a business lever, not just an engineering nicety.
1. Move the server closer (by far the biggest win)
The single largest improvement available to you is in-region hosting. Serving Southern and East African users from Johannesburg instead of Europe cuts 120–170 ms off every round trip. No clever code, cache or protocol tweak comes close to simply not sending the packet to another continent and back. If you do one thing on this list, do this one.
2. Peer at the local exchange
Where your server sits inside the region matters too. A facility peered at a major internet exchange — NAPAfrica in Johannesburg, IXPN in Lagos, KIXP in Nairobi — keeps traffic on the continent instead of “tromboning” out to Europe and back. That means fewer hops, lower and more stable latency, and resilience when a single subsea cable has a bad day. Scutex’s Johannesburg edge is peered at NAPAfrica for exactly this reason.
3. Cache aggressively
The fastest response is the one you don’t compute. Put static assets behind a CDN with African points of presence, and cache rendered HTML wherever your app allows it — full-page where you can, fragments where you can’t. Set sensible Cache-Control headers so browsers and the CDN stop asking your origin for things that rarely change. Self-host your fonts instead of pulling them from a third-party domain, which otherwise costs an extra DNS lookup, TLS handshake and round trip before text renders.
4. Tune TLS and the connection
- Enable HTTP/2 or HTTP/3 so many requests share one connection instead of racing for a handful.
- Use TLS 1.3 and OCSP stapling to shave a handshake round trip off every new connection.
- Keep connections alive — every fresh TCP + TLS setup is a round trip you pay before any data moves.
- Enable Brotli or gzip so less data crosses the slowest part of the path: the last mile to a mobile device.
5. Trim the back end and the payload
Once the network is short, your own code becomes the next bottleneck. Add database indexes for the queries your hot pages run, avoid N+1 queries, and keep a fast cache (Redis or Memcached) in the same region as your app so a cache hit is sub-millisecond. On the front end, ship less: compress and right-size images, defer non-critical JavaScript, and lazy-load anything below the fold. A lean page over a short network is what “instant” actually feels like.
6. Measure from where your users are
You can’t fix what you can’t see, and testing from your own laptop in another region hides the problem. Measure from African networks and mobile carriers, and track p50 and p95 latency per country — the p95 is where real users on congested mobile links live. Tools like WebPageTest with African test nodes, real-user monitoring (RUM), and synthetic checks from in-region probes will tell you whether your changes actually landed for the people you care about, instead of flattering you with an average.
The short version
Move the server in-region, peer locally, cache hard, tune the connection, trim the payload, and measure from the right place. The first step does most of the work — everything after it is polish. If your audience is in Africa, start by putting the server in Africa.