How to Choose a CDN for Global Websites: Start with Speed Tests by User Country

When choosing a CDN for an overseas-facing website, many teams start by opening the provider's global node map: how many points of presence are in North America, how many cities are covered in Europe, and whether Asia-Pacific also has broad coverage.

Such a map is useful for understanding general coverage, but it cannot directly answer a more important question:how fast your users actually experience the site.

Users lumped together as 'Southeast Asian' have very different network environments in Singapore, Indonesia, the Philippines, and Vietnam. Likewise, within the United States, the distance between the East and West Coasts, carriers, and origin fetch paths can differ markedly. A CDN that performs well in Tokyo does not mean all mobile users in Japan have a stable experience; many nodes in Frankfurt do not mean the entire European experience is good.

So the first step in choosing a CDN for an overseas-facing website is not to compare which provider has the lowest global average latency, but to list your own user countries and then arrange speed tests by country.

Why 'global average speed' can easily mislead CDN selection

Suppose a website's users are distributed as follows: United States 40%, Japan 25%, Germany 15%, Indonesia 10%, and all other countries 10% combined.

One CDN may perform well on a large number of low-cost test nodes and have an attractive global average, but be unstable on the U.S. West Coast or Japanese mobile networks. Another CDN may have a slightly higher global average but deliver more stable P95 and lower failure rates in the top four core countries.

For this website, the latter usually has greater business value.

Averages have another problem: they hide slow requests. If nine requests complete within 300 ms and one request takes 5 seconds, the calculated average may still look acceptable, but that one 5-second request was a real user's experience.

An overseas CDN test should at least look at the following together:

• Success rate and HTTP status codes;

• P50, P75, or P95 latency;

• DNS, TCP, TLS, TTFB, and download time;

• the difference between cache HIT and MISS;

• the degree of variance across countries, cities, and networks;

• whether performance degrades during local peak hours.

Google'sWeb Vitals documentationalso emphasizes that lab tests cannot replace real user data, because device capabilities, network conditions, and user behavior all change the final experience.

Active CDN speed tests are suited to comparing networks and delivery paths, while RUM is closer to what users actually experience when they open a page; the two should complement each other.

Step 1: Identify the countries that truly matter from your business data

Do not decide which countries to test based on team impressions. Start by reviewing data from the past 30 to 90 days:

• visitors and sessions by country;

• sign-ups, inquiries, purchases, or subscription conversions;

• revenue and average order value;

• request volume for key pages, static assets, and APIs;

• error rates and performance complaints by country;

• markets you plan to target or prioritize next.

If the website does not yet have live traffic, use marketing plans, ad targeting regions, customer lists, and pre-registration data to build an initial target-country list, but mark it as an estimate and revise it with real data after launch.

Do not rank countries by traffic alone

If a country accounts for only 5% of traffic but contributes 30% of revenue, its weight in CDN selection should not be just 5%.

Conversely, a location with a large amount of non-converting bot traffic should not automatically become the highest priority just because request counts are high.

You can group countries into three categories:

A practical approach is to first cover the countries that represent 80% to 90% of real users or business value, then add markets you plan to invest in over the next six months.

This percentage is not a fixed standard; the goal is to avoid spreading test resources evenly across dozens of unimportant countries in pursuit of 'global coverage.'

Step 2: One test location per country is not enough

Country is only the first layer; within a country, you also need to consider cities, carriers, and access types.

U.S. users may be spread across New York, Virginia, Chicago, Dallas, Los Angeles, and Seattle; Indian users may be concentrated in Mumbai, Delhi, and Bangalore; Japanese users may mainly come from Tokyo, Osaka, and various fixed and mobile networks.

If you test only from a capital city or cloud data center, the results are often ideal 'data center to data center' figures and may not represent home broadband and mobile users.

Consider at least three dimensions for each core country

City or region: cover major cities where users are concentrated, and include regions at different distances from the origin.

Network type: at minimum, distinguish between major local fixed broadband and mobile networks. If the business is mainly used in an app or mobile web, mobile networks should carry greater weight.

Test environment: data center probes are suitable for stable, repeatable tests, while residential and mobile networks are closer to real users. Use a combination when conditions allow.

You can build a test matrix as follows:

The cities in the table are planning examples only and cannot replace your own user data. The locations you should actually test must be based on access logs, RUM, orders, and marketing plans.

Step 3: Test real business URLs, not just ping the domain

Ping measures ICMP round-trip time. It can help reveal basic network latency or packet loss clues, but it cannot fully reflect DNS resolution, HTTPS handshakes, caching, origin fetches, or file downloads.

Some CDN nodes limit or deprioritize ICMP responses while HTTP service remains normal. It is also possible for Ping to be fast while a page loads slowly because of high TTFB, large assets, or cache misses.

For overseas CDN selection, prepare four types of test targets.

An HTML page that represents a real entry point

Choose the landing page, product page, or content detail page users visit most. It can reflect DNS, connection, TLS, HTML TTFB, and redirect behavior.

If the page includes login state or personalized content, do not force caching just for the test. What matters here is the actual delivery path, not artificially creating an attractive HIT.

A stable small static file

For example, a compressed logo, CSS, or small JavaScript file. It is suitable for checking node routing, cache status, and small-object latency.

A representative medium-sized file

Choose a product image, script bundle, or downloadable object commonly used in the real business to observe throughput and download time.

Do not create an oversized test file that never appears in the business and then use it to replace all conclusions.

A dynamic request that requires origin fetch

For SaaS, API, e-commerce, and login-based businesses, testing only static files is far from enough.

Choose a dynamic endpoint with no sensitive data that can be accessed repeatedly, and observe the CDN-to-origin path, connection reuse, and origin response time.

This helps avoid choosing a CDN that is fast for static images but slow for core APIs.

Step 4: Test cold cache and warm cache separately

The first request to the same URL may need to fetch from the origin, while subsequent requests are served by the edge node. Mixing the two results makes vendor comparisons meaningless.

During testing, at least label:

• MISSthe current node has no usable cache and needs to fetch from the origin;

• HITthe current node returns the cached copy directly;

• Agehow long the cached object has existed on the node;

• TTFB after an origin fetch and TTFB after a cache hit;

• whether the two requests connect to the same response IP.

You can request the same public static file repeatedly and inspect the response headers:

curl -sS -D - -o /dev/null \
  -w 'remote_ip=%{remote_ip}\ndns=%{time_namelookup}\nconnect=%{time_connect}\ntls=%{time_appconnect}\nttfb=%{time_starttransfer}\ntotal=%{time_total}\n' \
  'https://static.example.com/assets/test.jpg'

Keep the URL and request headers consistent across repeated runs. Do not add random parameters each time, or you may generate a new cache key and make every request look like a first visit.

Different CDNs do not use uniform cache response headers. For details on how to interpret them, seeHow to Read CDN Cache Hits: Understanding HIT, MISS, and Age.

When comparing candidate vendors, keep cache conditions fair: either test cold cache for all, or warm up all of them before testing warm cache. Do not compare vendor A's HIT results with vendor B's MISS results right after onboarding.

Step 5: Schedule speed tests by local time, not Beijing time only

Many overseas website speed tests are run during Chinese team working hours. For U.S. users, that may be the middle of the night; for European users, it may be before the evening peak.

If network congestion and carrier interconnection issues appear only during local evening peaks, a daytime test round can easily miss them.

For each core country, cover:

• local weekday mornings or afternoons;

• local evening traffic peaks;

• weekdays and weekends;

• business events, live streams, launches, or ad campaign periods;

• continuous sampling over at least several days.

You do not need to test every minute, but ensure different candidate CDNs use the same time windows and test frequency. A single fastest result proves that a CDN 'was once fast'; it does not prove long-term stability.

If the website itself sometimes feels fast and sometimes slow, see alsoHow to Test CDN Speed When Your Website Is Sometimes Fast and Sometimes Slow, and record the time period, carrier, response IP, and cache status together.

Step 6: Look at success rate and P95 first, then averages

Common speed test metrics for overseas websites include:

Success rate comes first because 'fast but often inaccessible' has no business value. Then look at P95 to uncover long-tail requests hidden by averages. P50 is suitable for observing the typical experience of most users.

Google's assessment of Core Web Vitals also uses a percentile approach and recommends using the 75th percentile to observe most users' experience; it also clearly notes that real user data can reflect differences in devices and network conditions.View Google Web Vitals documentation

This does not mean CDN speed testing must copy LCP or INP metrics, but it illustrates a shared principle: averages alone cannot represent all users.

Step 7: Build a country-weighted comparison table

Suppose the three candidate CDNs are A, B, and C. Score each one independently in each country, then aggregate by business weight.

Country weights can come from:

• share of real users;

• revenue or conversion contribution;

• future market investment;

• business impact of outages.

A simple calculation method is:

总评分 = Σ（国家评分 × 国家权重）

For example:

美国权重 40%
日本权重 25%
德国权重 15%
印度尼西亚权重 10%
其他目标市场权重 10%

Within a country, you can also weight by city and network. If mobile accounts for 70% of business traffic in Japan, data center probes and fixed broadband results should not each carry half the weight.

How to score each country

You can set different weights based on the nature of the business. The following is only an example for team discussion:

E-commerce can increase the weight of success rate and dynamic requests; video and download businesses can increase the weight of throughput, Range requests, and traffic cost; documentation-only sites can focus more on cache hit rate and static file speed.

Different metrics use different units, so milliseconds, percentages, and prices cannot be added directly. First normalize or bucket them across candidate vendors, then calculate weighted scores.

Step 8: Don't forget three costs beyond the CDN itself

Origin fetch distance and origin architecture

CDN nodes are close to users, but after a node MISS they still need to reach the origin.

If the origin is deployed only in Hong Kong while users are concentrated in Brazil, Germany, and the United States, first requests and dynamic APIs may still travel long distances.

If the share of dynamic business is high, consider regional origins, object storage replication, tiered caching, or origin acceleration rather than simply adding more edge nodes.

Regional pricing and origin fetch fees

CDN traffic unit prices may vary by region, and origin cloud providers may also charge for public egress, cross-region transfer, logs, and requests.

A CDN that is inexpensive in North America is not necessarily inexpensive in South America, India, or Oceania. During selection, plug projected traffic by country into official pricing rather than multiplying a 'lowest unit price' by total global traffic.

Prices and plans change quickly; formal decisions should be based on candidate vendors' current official quotes, contracts, and bill simulations.

Compliance, content, and data boundaries

A CDN may process IP addresses, request headers, cookies, logs, and security event data. Different countries and industries may have different requirements for data processing, cross-border transfer, log retention, and content distribution.

This part cannot be judged from a node map alone. Legal, security, and compliance staff should review vendor contracts, data processing terms, log regions, certificate and key management, and the local requirements applicable to the business.

Step 9: After active testing, validate with real user data

The advantage of active probes is controlled conditions: different CDNs can be compared repeatedly at the same locations, with the same URLs, and during the same time windows.

But probes cannot fully represent users' phone performance, home Wi-Fi, browser cache, and page interactions.

After launch, continue collecting RUM data by country, including at least:

• page or resource URL;

• country and region;

• network type;

• DNS, connection, TTFB, and page load metrics;

• device and browser category;

• HTTP status and error type;

• CDN or response node identifier;

• sampling time.

Google's Chrome User Experience Report aggregates qualifying real Chrome user experiences, but low-traffic pages or countries may not appear separately due to insufficient samples.

Google'sCrUX methodology documentationalso notes that country-level breakdowns may not be provided separately if they fail to meet sample requirements. Therefore, small and medium-sized overseas websites should build their own RUM rather than relying entirely on public datasets.

Active testing handles pre-launch screening and ongoing checks, while RUM verifies whether real users are actually getting faster. Only when the two data sets align is the selection conclusion more reliable.

How to use CDNChart to run a round of country-based speed tests

You can start by usingCDNChart Website Speed Testto enter your real business domain or a specific resource URL and view currently available monitoring locations in China and overseas, response IPs, status codes, and timing for each phase.

Keep three things in mind when using the results:

1. Only include monitoring countries and nodes that the platform actually provides today; do not assume countries without probe coverage will 'perform the same';

2. When a country has multiple nodes, look at the result distribution separately; do not keep only the fastest value;

3. If you find that different regions connect to different networks or providers, you can useCDNChart CDN Checkto verify CNAME, response IP, ASN, and response header clues.
   

If the platform does not yet have probes in the target country, nearby region results can serve as clues, but they cannot replace formal acceptance testing in the target country.

In that case, supplement with local cloud host probes, residential network tests, real user monitoring, or trial environments provided by the vendor.

For the boundary between CDN speed testing and full web page testing, see alsoWhat Is the Difference Between CDN Speed Testing and Website Speed Testing? What Can Each Measure?.

What if the best CDN differs by country?

This is actually quite common.

One CDN may perform well in North America and Europe, another may be more stable in Southeast Asia, and yet another may be notably cheaper in specific countries.

First assess whether the differences are large enough to justify added architectural complexity. If the gap is only a few dozen milliseconds, and multi-CDN adds costs for DNS routing, cache consistency, log aggregation, certificates, purge, and troubleshooting, a single CDN may be more reasonable.

If there are persistent, significant differences in success rate or P95 across core markets, consider:

• using different CDNs for different business subdomains;

• DNS or traffic routing by region;

• primary/backup CDN failover;

• multi-CDN for important markets and a single solution for long-tail regions.

Multi-CDN does not mean 'adding another vendor automatically makes things faster.' To interpret resolution results and how multiple vendors coexist, seeCan a Website Use Multiple CDNs? How to Read Results from Multiple Providers.

FAQ

For an overseas website choosing a CDN, should you look at node count or speed test results first?

Node count is suitable for initial screening; real country-based speed tests are better for decision-making.

More nodes do not guarantee better routing, carrier interconnection, or peak-hour performance in target countries. At minimum, validate with your own domain, business URLs, and target user networks.

Is testing one capital-city node per country enough?

Usually not.

Core countries should cover major user cities, fixed broadband, and mobile networks. For large countries, also consider East-West or North-South regional differences. Long-tail markets can be observed first with representative regional locations.

How long should speed testing last?

A single test only shows the state at that moment.

Formal selection should ideally cover several consecutive days, including weekdays, weekends, and local evening peaks in the target countries. If the business runs promotions, launches, or live streams, also validate under similar load.

If an overseas server is already close to users, is a CDN still needed?

It depends on whether users are concentrated, whether content is cacheable, and your security and availability requirements.

If users are concentrated only in the origin's city, traffic is very low, and most requests are dynamic, CDN benefits may be limited. If users are distributed across countries, there are many static assets, or you need to hide and protect the origin, a CDN can still add clear value.

Why are static files fast, but login and APIs still slow?

Static files can be returned directly after hitting edge cache, while login and APIs usually require origin processing.

You should continue checking the CDN-to-origin path, origin region, database, and application latency rather than just increasing cache TTL.

Can you simply choose the CDN with the lowest global average latency?

Not recommended.

A global average does not reflect the weight of your user countries and can easily mask regional failures and P95 long tails. A more reasonable approach is to compare success rates and percentiles in each target country first, then weight by users, revenue, and strategic value.

When is multi-CDN worth using?

Multi-CDN is more valuable when different vendors consistently outperform in different core countries, or when the business must have vendor-level failover capability.

If the performance gap is small and the team's operations capacity is limited, the added complexity of another CDN may outweigh the benefits.

The right CDN for an overseas website does not have to rank first in every country, but it should be stable, explainable, and cost-controlled in the most important user countries. Start with a country list derived from real business data, then let speed test results drive selection; this is usually closer to the right answer than starting from a global node map.