The CDN Doesn’t Save You From Geography
Origin Still Matters
Each test we run goes from one of five regions to whatever destination the person running it picks, Cape Town, Frankfurt, Singapore, St Louis, Sydney. Nobody runs all five at once, and it isn’t automatic or at least not when testing via enterramon.com, someone selects the region per test. But across enough individual tests, run one at a time over the current testing period, we’ve built up a few thousand results spread across all five, and we’d never lined them up against each other by distance before. Across the current testing base that’s a few hundred unique domains and a few thousand individual test runs, enough to pull real patterns out rather than anecdotes, so we did the comparison properly instead of guessing at it. The short version: distance still costs you real milliseconds, a CDN cuts that cost hard but doesn’t erase it, and the report you’re looking at right now can’t actually tell you where a site is hosted if it’s sitting behind one.
Most of what gets written about web performance treats “slow” and “fast” as properties of a site, full stop. Fewer people ask the more useful question, slow or fast for who, and from where. A site can pass every check from its own backyard and still be handing distant visitors a genuinely poor experience, and the report itself has no way of flagging that unless you actually go and test it from somewhere else.
The metric doing most of the work in this piece is time to first byte specifically, not full page load. TTFB is the part of the timeline that’s actually about the network trip and the server’s own response, before rendering, before assets, before anything the browser does with what it received. That’s exactly the layer where geography and hosting quality live, which is why it’s the right lens for this argument even though it isn’t the only number that matters for how a page feels to load.
This is what we found
The Distance Penalty, Without a CDN in the WayStart with the cleanest comparison we have, sites with no CDN detected, .co.za domains specifically, since we can isolate them by TLD rather than by IP geolocation. Tested from Cape Town, average TTFB comes in at 701ms. Tested from Frankfurt, the same population of sites averages 1819ms.
If any of this sounds like a narrower version of the same territory we covered in our first look at the aggregate dataset, it is, deliberately. That piece looked at scores, infrastructure, and tech stack averaged across every test regardless of where it ran from. This one splits the same kind of testing base by distance instead, which is a different question with a different answer.
That’s not a fluke of one dataset either. We see the identical shape in US-hosted sites with no CDN, tested from five different regions:
Avg Desktop TTFB, No CDN, US-Hosted
Two completely different origin populations, two independent confirmations of the same underlying fact, the further the test, the worse the number, and it isn’t subtle. Google’s own guidance on Time to First Byte puts anything under 800ms in the good band and anything over 1800ms in poor, and several of these no-CDN, cross-region numbers land squarely in that poor territory. A site that looks perfectly healthy from its own backyard can be sitting in the red zone for half the planet.
One number in that table looks backwards at first glance, Frankfurt beats St Louis to the same US-hosted population despite St Louis being domestically closer. Worth being upfront that “US-hosted” here isn’t one location, it’s whichever US-registered IPs turned up in the sample, and Frankfurt may simply be hitting a better-peered subset of them rather than physics running in reverse.
Worth being straight about what we’re not showing here too. The raw ICMP ping figures for this same table came back physically impossible, sub-15ms for a transatlantic round trip is well below the minimum propagation delay fiber allows, so we’ve pulled that ping comparison rather than publish numbers that don’t survive basic physics. The likely explanation ties back to the same CDN-detection limitation we get into later, our server technology check flags CDNs by matching known HTTP header signatures, but ICMP pings often get answered by an edge, firewall, or anycast health-check node closer to the tester regardless of whether the HTTP layer looks CDN-fronted. TTFB reflects the real HTTP transaction wherever it actually terminates, ping doesn’t necessarily hit the same place, which is probably why the TTFB numbers above hold up and the ping numbers didn’t.
Connection time offers a way to check that instinct without relying on ICMP. A TCP or TLS handshake genuinely has to complete with whatever’s actually listening, so it’s a real network round trip even when a bare ping isn’t. For the same non-CDN, US-hosted population, connection time and TTFB rise together in four of the five regions, EU-FRA at 25.7ms connection and 310ms TTFB, US-STL at 45.9ms and 512ms, AF-CPT at 67.9ms and 541ms, OC-SYD at 83.3ms and 840ms. Same shape as the TTFB table on its own, distance tracking distance.
Singapore breaks it, and in a genuinely instructive way rather than an annoying one. In that same non-CDN, US-hosted slice, connection time there is the lowest in the table, 10.3ms, while TTFB is the highest, 967ms, worth flagging that this is a narrower population than the all-countries connection-time table earlier in the piece, where Singapore’s average connection time came out considerably higher, two different slices of the same dataset, not a contradiction. A handshake can complete fast against a nearby edge or health-check responder while the actual HTTP request still has to travel on to wherever the origin really sits, paying the real distance cost after the connection opens rather than during it. TTFB catches that leg of the trip, connection time doesn’t, for essentially the same reason ping didn’t either.
What a CDN Actually Buys YouSame .co.za domains, now split by whether a CDN was detected in front of them.
Tested locally from Cape Town, CDN-fronted sites average 540ms TTFB against 701ms for sites with no CDN, roughly 23% faster, even though the visitor was never far away to begin with. Ping barely moves between the two groups, so this isn’t a distance effect at all, it’s the edge doing real work on cache hits and connection handling that a plain origin server has to do the hard way every time.
Tested from Frankfurt, the gap opens up properly. Ping drops by two thirds, TTFB drops by almost half. The 48ms ping figure lines up with what you’d expect from a nearby edge answering the request rather than a full round trip to Cape Town, which is the CDN doing exactly what it’s built to do.
Worth flagging plainly, the CDN side of that Frankfurt comparison is only 5 tests. Directionally it’s consistent with the mechanism, and the ping number in particular matches what edge routing should produce, but it’s a thin sample, treat the size of that gap as illustrative rather than a precise measurement, the direction is the finding, not the exact percentage.
It’s not just one country’s domains showing this
German sites tested from Frankfurt, split the same way, show a bigger CDN gap than the local South African comparison even though the visitor is practically next door either way. Australian sites tested from Sydney show the same local-benefit pattern too. Three separate country populations, three separate confirmations that a CDN helps even when distance isn’t the problem, which rules out the South African numbers being some quirk of that specific hosting market.
The CDN effect isn’t perfectly clean everywhere, though. US-hosted sites tested from Frankfurt with a CDN detected still average 113ms ping, worse than several no-CDN rows in the same table. Small sample again, 7 tests, same rule applies, read the direction, not the exact size of the gap. It’s a reminder that a CDN tag in a report isn’t a guarantee of a nearby edge for every visitor, it depends on where that specific provider actually has infrastructure. Presence of a CDN moves the odds a lot, it doesn’t universally flatten every route.
TTFB isn’t one number, it’s DNS lookup plus connection setup plus however long the server takes to actually respond. Breaking it out by region:
Avg DNS Time
Avg Connection Time
Avg TTFB
DNS lookup time doesn’t track with overall speed at all, US-STL has the fastest DNS resolution in the dataset and still isn’t the fastest region overall. Connection time does track, though. Singapore and Sydney carry both the highest connection times and the highest TTFB in the table. That tracks with how a TLS handshake actually works, it isn’t one trip, it’s several, so every extra bit of distance between visitor and server gets paid multiple times before a single byte of content moves. DNS lookup is a fixed, mostly-cached cost, which is why our DNS tool checking propagation and record consistency won’t tell you much about this particular problem. Connection setup is the one that scales with how far away you actually are, and if you want to see exactly which hops are adding that time, that’s what a traceroute is actually for, walking the path hop by hop instead of just totalling up the damage at the end.
DNS and connection time don’t account for all of it though. Take AF-CPT’s 500ms average TTFB, strip out 51ms of DNS and 48ms of connection setup, and there’s still around 400ms unaccounted for. That remainder is the server actually doing the work, and distance has nothing to do with it. Shared hosting on oversubscribed CPU and RAM, a database running slow queries against an unoptimised table, a theme dragging in more than the page needs, all of that shows up in exactly this part of the number regardless of how close the visitor is. A site next door to its visitors on cheap, contended hosting can still lose to a further-away site on properly resourced NVMe storage and a database that isn’t fighting for CPU time. Location and CDN presence explain the network side of TTFB, the server itself still has to answer fast, and that part comes down to what you’re actually paying for.
The pattern in our broader dataset has generally been that mobile tests come back faster than desktop. Splitting that by region mostly holds up, except in one place:
Avg Desktop TTFB
Avg Mobile TTFB
Cape Town breaks the pattern. Desktop averages 500ms there, mobile averages 572ms, mobile running slower by 73ms, while every other region shows mobile 20-76ms faster than desktop. We don’t have a confirmed reason for that yet, our best guess is sample composition, Cape Town carries by far the largest share of total tests in this dataset (1,984 of them, against a few hundred each for the other regions), so it’s more likely to reflect whatever the underlying site population actually looks like rather than some property of the region itself. Flagging it honestly rather than explaining it away, because we don’t have the data yet to say more than that.
There’s a smaller oddity sitting next to it too. A handful of tests, five of them, show up under a slightly different Cape Town label with a much faster average TTFB, 306ms against the main pool’s 500ms. Too few tests to draw a conclusion from, possibly a second node, possibly an early data point from before the current setup stabilised, we’re not going to guess at it in print. It’s staying in the raw numbers rather than getting smoothed out, because a pillar piece that quietly drops the inconvenient rows isn’t one you should trust either.
Here’s a limitation worth being upfront about, because it shapes how you should read any report, ours included. Once a domain sits behind a CDN, every test from outside only ever reaches the edge server, never the origin. There’s no way to observe where the actual hosting lives from that vantage point. This isn’t a gap in our tooling specifically, it’s inherent to how anycast routing works, when an anycast network proxies an origin server, the apparent latency to that IP reflects distance to the edge of the anycast network rather than to the origin itself, meaning real latency to the origin can’t be determined by probing from outside.
Practically, that means a country field on any test result tells you where the responding IP geolocates, which for a CDN-fronted site is wherever that provider’s edge network puts it, usually the US for the big providers, regardless of where the domain is actually registered or hosted. Our own server check will happily tell you the ASN and IP behind a domain, and for a CDN-fronted site that’s genuinely useful information about the network handling the connection, it just isn’t the same thing as knowing where the origin server physically sits. Those are two different questions that look like one question until you actually need the answer to the second one.
None of this means CDN presence makes origin location irrelevant. A CDN caches static assets close to the visitor, but anything dynamic, uncached, or personalised still has to round-trip to the real origin, and that round trip pays the same distance tax we’ve been measuring throughout this whole piece. A site hosted in Europe with a CDN in front will serve a cached image fast to a visitor in Cape Town, the underlying page logic still travels to Frankfurt and back.
Take an online store as the concrete case. Product images, CSS, the main page shell, all of that can sit on the edge and load fast for anyone anywhere. The cart total, stock check, and payment step can’t, those need a live answer from wherever the actual application server lives, and that leg of the journey is exactly the connection-setup and server-response time we broke down earlier. A store with European visitors and a European origin pays that cost once, briefly, on the parts that matter least to first impression. A store with the same setup but a majority-African customer base pays it on every checkout, which is a worse trade even with a CDN doing everything else right.
Which means the actual decision hasn’t changed much even with a CDN in the picture, host close to where your real audience sits, and use the CDN to reduce the penalty for everyone else, not to replace the choice of where the origin actually lives.
Unique domains and total tests by region
These figures come from live testing across the five regions we run, and the base is heavily skewed toward Cape Town, not just in test count but in domain count too. Cape Town carries 341 unique domains across nearly 2,000 individual tests. Everywhere else is a smaller slice: Frankfurt at 168 domains and 398 tests, St Louis at 204 domains and 344 tests, Sydney at 70 domains and 91 tests, Singapore at 32 domains and 55 tests. Cape Town domains also get tested more often on average than domains elsewhere, so this isn’t an even sample of the web sliced five ways, it’s whatever’s actually been run, weighted hard toward one region and toward whichever domains happened to get tested there repeatedly. The CDN-versus-no-CDN Frankfurt comparison earlier in particular rests on a small sample and should be read as directionally consistent with the underlying mechanism rather than a precise measurement.
Full current figures, updated continuously, are available on our global analytics page. If you want to see where your own site lands against any of this, run a test from whichever region matters most to your actual visitors, not just the one closest to you.
Data collected and published by Enterramon. Testing conducted across the regions listed above using real browser automation. All domain data anonymised prior to aggregation.
Thank you for taking the time read this, please share it if you found it interesting.
