A CDN map shows where a provider has placed servers, not how fast your users reach them. The gap between the two is measurable: every 100 km of fiber between a user and the serving Point of Presence (PoP) adds roughly 1 ms of round-trip time (RTT), and a cold HTTPS request on TCP with TLS 1.3 spends about three round trips before the first byte of a cached file arrives. This article gives you a region-by-region latency table with dated ranges, a worked calculation that converts map distance into first-byte time, a checklist for reading any CDN PoP map, and a best-fit matrix by region and workload.
In 2026, the most useful way to read a CDN map is as a latency floor calculator: a user 2,000 km of fiber away from the nearest PoP pays at least 20 ms per round trip, or about 60 ms on a cold TLS 1.3 connection, before congestion or routing detours. A dot on the map only helps if traffic is actually routed to it, which depends on peering and request steering, not on the dot.
A provider's map is a marketing artifact built from inventory, not from traffic. It tells you where hardware exists. It does not tell you which users that hardware serves, how much capacity sits behind each dot, or whether the local ISPs exchange traffic with it.
Three distinctions matter before comparing maps across vendors:
A CDN PoP map lists locations; real coverage is the share of your users served from a site in their own country or metro over a short network path. The two diverge when a PoP lacks peering with dominant local ISPs, runs out of capacity at peak, or sits outside the Anycast catchment of nearby networks.
For background on how PoPs, tiered caches and shields fit together, see the CDN fundamentals and PoP explainer hub.
CDN latency by region varies more inside a region than between major providers. Public real-user measurements from 2024 to 2026 put median edge RTT for metro users in North America and Western Europe at roughly 10 to 25 ms, while Africa, the Middle East and inland South America commonly sit at 30 to 90 ms, with p95 values two to four times the median.
The ranges below are this blog's estimates synthesized from public traffic measurements published 2024 to 2026. They describe well-provisioned commercial CDNs as a class, not any single vendor, and they are not a ranking.
| Region | Median edge RTT, metro users (estimate) | Typical p95 (estimate) | What drives the tail |
|---|---|---|---|
| North America | 10 to 25 ms | 40 to 80 ms | Rural access networks, mobile last mile |
| Western Europe | 10 to 25 ms | 35 to 70 ms | Dense IXPs keep paths short; tail is mostly mobile |
| Eastern Europe | 20 to 40 ms | 60 to 120 ms | Backhaul to Frankfurt, Vienna or Stockholm |
| East and Southeast Asia | 15 to 40 ms | 60 to 150 ms | Expensive regional transit, routing via Singapore or Hong Kong |
| India | 25 to 60 ms | 80 to 200 ms | Mobile-heavy traffic, uneven ISP peering |
| South America | 20 to 50 ms | 80 to 180 ms | Good in Brazil, longer paths in Andean countries |
| Middle East | 25 to 60 ms | 90 to 200 ms | Traffic hairpinning through Europe |
| Africa | 30 to 90 ms | 120 to 300 ms | Many countries still backhauled to Europe |
| Oceania | 10 to 30 ms in major cities | 60 to 150 ms | Island networks and remote areas |
The median-to-p95 spread inside one region is usually larger than the median gap between major CDNs, so regional p95, not a global average, is the number to compare.
Headline numbers use incompatible definitions. In 2025 vendor documentation, Cloudflare described its network as spanning 330+ cities, Amazon CloudFront listed 600+ points of presence plus regional edge caches, and Akamai counted locations in the thousands, many of them embedded inside ISPs. A city, a PoP and a server cluster are different units.
Past roughly 100 well-placed sites, additional dots in already dense regions rarely move metro medians by more than a few milliseconds; they matter when they land in an underserved country or inside a large access ISP. What decides real coverage is peering density, capacity at peak, and whether steering actually reaches the nearby site.
The arithmetic is simple enough to apply to any map. Fiber RTT floor in milliseconds is roughly the route length in km divided by 100. Real routes run about 1.4 times the great-circle distance. Add around 10 ms for the access network. A cold HTTPS request on TCP with TLS 1.3 for a cached object needs about three round trips: TCP handshake, TLS handshake, then request and response. QUIC with HTTP/3 removes one.
| User and serving site | Great-circle km | Estimated RTT | Cold TTFB, 3 RTT |
|---|---|---|---|
| Johannesburg user, Johannesburg PoP | about 20 | about 10 ms | about 30 ms |
| Johannesburg user, London PoP | about 9,000 | 126 + 10 = 136 ms | about 410 ms |
| São Paulo user, Miami PoP | about 6,600 | 92 + 10 = 102 ms | about 305 ms |
| Sydney user, Singapore PoP | about 6,300 | 88 + 10 = 98 ms | about 295 ms |
Serving a user from the wrong continent adds roughly 250 to 400 ms to a cold first byte, an order of magnitude more than the median difference between major CDNs in well-served metros.
This is the practical meaning of a CDN map: it tells you the best case. One misrouted ISP in Johannesburg costs more than every vendor-to-vendor gap in a typical global benchmark, and it will not show up in a global average.
Regional numbers are only comparable when the method is fixed. A defensible test uses the same object sizes you serve (a 10 KB asset and a 100 MB file behave differently), separates cold-connection from warm-connection TTFB, runs for at least seven days to capture weekday peaks, and reports p50, p95 and jitter per country and per ISP autonomous system (ASN). Synthetic probes in data centers flatter every provider; real-user measurements from browsers or apps reflect access networks.
A provider with excellent p50 and a poor p95 in one region delivers a worse experience there than a provider that is slightly slower at the median. Rank providers per region on p95, then check that the ranking holds during local evening peak.
Measure the share of requests answered by a PoP in the user's own country. Most CDNs expose the serving site in a response header: Cloudflare appends an airport code to the cf-ray header, Amazon CloudFront returns x-amz-cf-pop, and Fastly reports nodes in x-served-by. Log that header in your real-user monitoring and join it with user country and ASN.
Map coverage should be weighed against what you deliver. Interactive traffic is dominated by RTT; bulk files are dominated by throughput and cost per TB, where an extra 20 ms of RTT barely matters on a multi-gigabyte download.
| Workload or footprint | Best fit | Why | Honest limitation |
|---|---|---|---|
| Global APIs and SaaS | Cloudflare, Fastly | Edge compute, HTTP/3, programmable caching | Fastly runs fewer sites in Africa and South America; verify regional p95 |
| Global live video at large scale | Akamai, Amazon CloudFront | Deep ISP-embedded footprint, peak capacity | Akamai publishes no price list; CloudFront price classes can exclude regions |
| High-volume VOD, software, game patches | BlazingCDN, bunny.net | Throughput and cost per TB matter more than RTT | BlazingCDN has no HTTP/3 and no WAF; bunny.net's Volume network uses fewer locations than its Standard network |
| Regional e-commerce on a public cloud | Google Cloud CDN, Cloudflare | Tight integration with load balancing and caching rules | Google Cloud CDN is tied to Google Cloud load balancing |
| Users concentrated in Africa, Middle East or Andean South America | Whichever provider shows the highest in-country serve rate on your top ASNs | Local peering beats global PoP count | Only a per-ASN test reveals it |
| Mainland China | A licensed in-country network | Cross-border paths add large, variable latency | Requires an ICP filing and a separate contract |
No single map wins every row: pick by the workload that dominates your bytes, then confirm coverage in the regions that dominate your users.
BlazingCDN publishes this blog, so treat its row as a claim to verify on your own traffic; its 14-day testing period on real production traffic exists for that.
For heavy static delivery, BlazingCDN states performance as measurements rather than a map: on a 100 MB HTTPS download measured June 2026, Europe 27 ms and 1.12 Gb/s, North America 24 ms and 1.11 Gb/s, Asia 47 ms and 761 Mb/s, on NVMe SSD servers with Anycast routing and built-in failover. It can also run as a second CDN behind DNS with a weighted traffic split, which lets you keep an interactive-traffic provider for APIs and move bulk files separately; the CDN comparison by workload and cost lays out where each provider fits.
A CDN network map is a provider's published view of where its PoPs, regional caches and sometimes backbone links are located. It shows hardware placement, not performance. Two providers with similar maps can deliver very different regional latency because peering, capacity at peak and request steering decide which site actually answers each user.
A CDN PoP map predicts only the best-case latency floor, roughly 1 ms of RTT per 100 km of fiber route. Actual latency depends on whether users reach the nearest PoP. Misrouting through a resolver mismatch, Anycast catchment drift or a plan that excludes the region can add 250 ms or more to a cold first byte.
Africa, the Middle East, India and inland South America typically show the highest CDN latency, with public measurements from 2024 to 2026 suggesting median edge RTT around 30 to 90 ms and p95 above 120 ms. The main cause is backhaul to Europe or North America when local PoPs lack peering with dominant ISPs.
Read the serving-site response header your CDN returns. Cloudflare appends an airport code to cf-ray, Amazon CloudFront returns x-amz-cf-pop and Fastly lists nodes in x-served-by. Log that header in real-user monitoring alongside user country and ASN to compute an in-country serve rate, which reveals coverage gaps the map hides.
No. Beyond roughly 100 well-placed sites, additional PoPs in dense regions rarely move metro medians by more than a few milliseconds. More dots help when they land in underserved countries or inside large access ISPs. Peering quality and peak capacity in your users' regions matter more than the global headline count.
Take seven days of real-user data and group TTFB by country and ASN. For your top ten ASNs, record p50, p95 and the serving PoP from the response header, then apply the RTT formula from the worked example to flag any ISP served from another country. Those flagged rows are where a different provider, a second CDN or a plan change will move user-visible latency, and they cost nothing to find. If bulk files dominate your bytes, the BlazingCDN performance metrics page and public test file let you run the same throughput and latency check from your own networks before any commitment.