Is your site slow because of the code or the distance? Hosting for South African sites

Published 16 Oct 2026

Graphic for the guide Is your site slow because of the code or the distance, with a bar chart of median ping times from South Africa: Cape Town to Johannesburg 19 ms, Johannesburg to London 167 ms and Johannesburg to New York 239 ms.

Your site feels slow, your developer blames the host, and the host blames the plugins. Before anyone gets paid to fix the wrong thing, it helps to know which kind of slow you have. One kind is the code: the server takes too long to build the page. The other is distance: the page is ready quickly, but every request has to travel to a server on another continent and back.

For South African sites this matters more than usual, because plenty of them are still hosted in Europe or the US. Here's how to tell the two apart, with real numbers.

How far is far? Real ping times from South Africa

WonderNetwork runs 30 pings between major cities every hour and publishes the results. These are the median round-trip times over the two weeks from 2 to 16 October 2026:

Bar chart of median ping times from South Africa: Cape Town to Johannesburg 19 ms, Johannesburg to Nairobi 52 ms, Cape Town to London 141 ms, Johannesburg to London 167 ms, Johannesburg to Frankfurt 174 ms and Johannesburg to New York 239 ms.
Median round-trip times, 2 to 16 October 2026. Source: WonderNetwork global ping statistics.

One round trip to Europe looks harmless at 0.17 seconds. The catch is that a first visit needs several of them before any content arrives: one to open the connection, at least one more to set up HTTPS, and one for the request itself. Three round trips to Johannesburg cost under 0.1 seconds. Three to London cost about half a second, and that's before the server has done any work.

What TTFB tells you

Time to First Byte (TTFB) is the time from asking for a page to receiving the first byte of it. Google's web.dev guide to TTFB counts everything from redirects and the DNS lookup up to the first byte of the response arriving. It suggests most sites aim for 0.8 seconds or less. It isn't a Core Web Vitals metric, but a slow TTFB pushes back everything after it, including Largest Contentful Paint.

Distance shows up in the connection part. Slow code shows up in the wait after the request is sent. You need to split the two.

How to tell code from distance

1. Measure TTFB from where your customers are

If you have a terminal (Mac, Linux, or Windows with curl), run this from a South African connection, using your own address:

curl -o /dev/null -s -w "connect %{time_connect}s tls %{time_appconnect}s ttfb %{time_starttransfer}s\n" https://yourdomain.co.za/

Run it three or four times and ignore the first result, which includes the DNS lookup. No terminal? The Network tab in Chrome's DevTools shows the same phases when you click on the page request and open Timing.

2. Split the connection time from the server time

The connect figure is roughly one round trip to the server. If it's around 0.15 to 0.25 seconds from South Africa, your server (or the part of it you're reaching) is probably in Europe or the US. Now subtract tls from ttfb. What's left is one more round trip plus the time the server spent building the page. If that gap is large and the connect time is small, the problem is the code or the server, not the distance.

Illustration comparing two curl timing results. A site hosted far away has a slow connect time and a short server wait. A site with slow code has a fast connect time and a long server wait.
Illustration with example timings. Long bars at the start mean distance. A long bar at the end means the server is slow to build the page.

3. Compare a nearby and a far test location

Run the same test from a location close to your server and from one far away. WebPageTest, which web.dev lists as a lab tool for TTFB, lets you pick a test location. If TTFB is fast near the server and slow from South Africa, distance is your problem. If it's slow from everywhere, it's the code or the server.

4. Compare a cached and an uncached request

Load the page twice, then once more with a made-up query string on the end, like ?nocache=123. Many page caches skip URLs they haven't seen before, so that request is often built from scratch. A cached page that comes back quickly and an uncached one that takes a second or more points to slow code, too many plugins or a struggling database. Our guide to why websites are slow covers those fixes.

Rather not run commands? The free CrawlCare scan runs Lighthouse on your page and reports server response time alongside the rest of your speed and SEO results.

Hosting with data centres in or near South Africa

If most of your visitors are in South Africa, hosting here removes most of the distance. If they're mostly in the UK or Europe, the same logic says host there. These options have South African data centres, checked on 16 October 2026:

Moving host fixes distance. It doesn't fix a page that takes two seconds to build. That's why it pays to measure first.

Quick summary

  1. Run the curl test from South Africa a few times.
  2. Slow connect time (0.15 s or more) means the server is far away.
  3. Fast connect time but a long wait for the first byte means slow code or a slow server.
  4. Slow only on uncached requests means caching is hiding a slow build.
  5. Pick a host near your customers, then fix the code that's left.

Want a second opinion? Run the free scan, or see our Speed Fix if you'd like us to sort it out.

Further reading