If your users are mainly in mainland China, which regions and carriers should you focus on when choosing a CDN?

'We have many CDN nodes across the country.'

This may sound appealing, but it doesn't answer a more practical question:When my users visit, is it actually fast?

Mainland China's network environment is not a uniformly spread network. The same website may load smoothly on China Telecom in Shanghai, but that doesn't mean it performs the same way on China Mobile in Guangzhou, China Unicom in Beijing, or China Telecom in Chengdu. Even if two users are in the same city, different access carriers may route them to different nodes and over different network paths.

Therefore, when choosing a CDN for users in mainland China, you cannot look only at a provider's total number of nodes, nor can you test by opening the website once from your own office. A truly useful selection method is to first determine where your users are and what networks they use, then build a 'region × carrier' test matrix.

First, the conclusion: test all three major carriers, and prioritize regions by your real user distribution.

If most of your website's users are in mainland China, China Telecom, China Unicom, and China Mobile are usually must-test items. As for which cities to test first, you should not simply copy a fixed 'national key city list'; start with your own access logs or analytics platform.

You can divide the test scope into three tiers:

If budget or testing resources are limited, it is better to test all three major carriers in three core cities first than to test only one carrier across ten cities.

Comparing different carriers within the same city often reveals problems more easily than testing the same carrier across many cities.

Why can the three carriers produce different results in the same city?

A CDN does not simply send every user to the geographically closest node. Actual routing is also affected by DNS resolution, carrier networks, node load, network interconnection, and CDN scheduling policies.

For example, three users in Hangzhou:

• A China Telecom user may hit a China Telecom node in Hangzhou or Shanghai;

• A China Unicom user may be routed to a different China Unicom-covered node;

• A China Mobile user may hit a China Mobile line node, or may experience cross-network access.

A node's physical distance is only one factor. Even if a node is not far from the user, if there is cross-carrier interconnection, detouring, or congestion in between, TCP connection time and time to first byte can still be high. Conversely, a slightly farther node with better line quality may actually provide more stable access.

This is why a 'large number of nodes' does not directly equal 'fast user access.' Node deployment locations, egress capacity, carrier interconnection quality, scheduling accuracy, and peak load all affect the final result.

First draw your own user map; do not replace it with a national average

Before contacting CDN vendors or starting a trial, answer a few questions using website analytics, server access logs, order data, or client-side monitoring:

• Which provinces and cities do users mainly come from?

• What percentages are China Telecom, China Unicom, and China Mobile? Are there many China Broadcasting Network or campus network users?

• Do users mainly use fixed broadband or mobile networks?

• Which regions contribute only traffic, and which contribute registrations, orders, or payments?

• When are traffic peaks? Do evenings and weekday daytime perform differently?

• Do users mainly access web pages, small images, downloadable files, video, or API endpoints?

Here is a detail that is easy to overlook:Traffic share does not equal business weight.

A region may account for only 10% of traffic but contribute 25% of orders. If you still allocate weight evenly by visit count, the CDN you ultimately select may perform well in 'high-traffic, low-value' areas while slowing down the transaction users who really matter.

If you do not have complete statistics, you can first use the last 30 days of access logs to build an initial distribution, then gradually add real user monitoring. Do not use a CDN vendor's national average results in place of your own user structure, because averages hide local problems.

Which representative regions should be selected in mainland China?

The table below is suitable for filling out national coverage, but it is not an unchangeable standard answer. Representative cities can be replaced based on user distribution and test node availability.

More test cities are not always better. A more practical approach is: first cover major revenue regions, then add representative points for major regions not yet covered. If a province continuously shows complaints or a high timeout rate, drill down to different cities and carriers within that province.

For local businesses with highly concentrated users, the test scope can be even narrower. For example, if the vast majority of users are from Guangdong, you should first test China Telecom, China Unicom, and China Mobile in Guangzhou, Shenzhen, and other core cities in detail, rather than spreading limited samples evenly across dozens of cities just to appear to have 'national coverage.'

Beyond China Telecom, China Unicom, and China Mobile, should other networks also be tested?

China Telecom, China Unicom, and China Mobile: usually basic must-test items

These three types of networks cover most common access scenarios. If any one of them has an obvious weakness, it may create a group of users who say, 'Everyone else says it's fast, but I can't open it.'

However, you should not test only one point for each of the three carriers. Good performance on China Unicom in Beijing does not mean China Unicom users in Northeast or Northwest China will have the same experience; fast speeds on China Mobile in Guangzhou do not represent China Mobile in Southwest China. The carrier dimension needs to be viewed in combination with the region dimension.

China Broadcasting Network: prioritize based on user composition

If your business has many home broadband, TV, or lower-tier market users, you can add China Broadcasting Network to the trial scope. If there are very few such users in your logs, you do not need to give it too much weight in the first round of selection.

CERNET: must be evaluated separately when there are many campus users

Businesses such as online education, academic paper resources, developer tools, and campus communities may have many CERNET users. In this case, testing only the three major carriers is not enough.

Access paths on CERNET differ somewhat from ordinary public networks and should be verified through actual campus network tests or real user data.

Enterprise dedicated lines, government extranets, etc.: do not substitute public network test results

If customers access through dedicated lines, office networks, or controlled networks, ordinary public network probes can only serve as a reference. A more reliable approach is to perform low-risk verification within the real customer network and check whether proxies, firewalls, DNS, and egress policies are involved in the access process.

For different businesses, even with the same regions and carriers, metric priorities differ

Choosing a CDN should not just mean asking 'What is the average latency?' The same set of nodes may be great for a news site but not necessarily suitable for large file downloads or dynamic APIs.

For gaming businesses, you also need to distinguish between resource distribution and real-time connections. CDNs are suitable for distributing installation packages, patches, images, and static assets, but real-time match connections usually require a dedicated network acceleration solution and cannot be replaced by a static file speed test result.

When selecting, look at availability first, then P95

A test point occasionally producing a very fast result is not very meaningful. Users visit thousands of times every day, and what truly affects experience is 'how fast it is most of the time' and 'how bad the slowest portion is.'

It is recommended to observe in the following order:

1. Availability, timeout rate, and error rate: If requests fail frequently, even a fast average speed should not make it into the final candidates.

2. P95 latency: It is more likely than a single fastest result or a simple average to expose peak congestion and occasional slow requests.

3. P50 latency: Used to understand everyday, typical access levels.

4. TTFB, TCP, and TLS time: Helps determine whether slowness is in the connection, handshake, node processing, or origin fetch.

5. Download throughput: More important than TTFB alone for installation packages, video, and large images.

6. Cache hit ratio and origin traffic: Determines whether users actually fetch content from edge nodes, and also affects origin pressure and cost.

7. DNS resolution and scheduling results: Observe which node different regions and carriers are assigned to, and whether there is long-distance scheduling or cross-network access.

Tencent Cloud CDN's official monitoring documentation also uses bandwidth, traffic, request count, traffic hit ratio, status codes, etc. as access monitoring metrics and supports filtering by region or carrier. This shows that CDN evaluation itself should not be reduced to a single 'latency' metric. SeeTencent Cloud CDN access monitoring documentation.

Alibaba Cloud CDN real-time monitoring also provides filtering dimensions such as region and carrier. SeeAlibaba Cloud CDN real-time monitoring documentation.

If you are not familiar with P50, P95, and sample size, you can first readCDNChart testing methodology. Once you understand percentiles, you will be less likely to be misled by one very attractive speed test result.

How should weights be assigned to regions and carriers?

The simplest approach is to make the selection score close to the real business:

Overall result = test results for each 'region × carrier' × user share × business value weight

Assume a website's users mainly come from East China and South China; you can create the following test table. The numbers below are only to demonstrate the calculation method and are not recommended proportions for any industry or website.

Do not create a false sense of precision just to get an '89.7 score.' The purpose of weights is to prevent a large number of test samples from low-value regions from drowning out core markets, and to prevent a vendor from winning an overall comparison based on a few advantageous nodes.

You can also set elimination thresholds: for example, if a core region continuously has obvious timeouts, or a key carrier's availability is below business requirements, then even if the overall score is acceptable, do not move to the formal migration stage yet.

Specific thresholds should be determined based on your own SLA and historical baseline, not copied from someone else's numbers.

How can an executable round of CDN trial testing be conducted?

First, useCDN rankingsandCDN vendor comparisonto shortlist 2 to 4 candidate services, then apply for testing or a small-traffic trial. Keep test conditions as consistent as possible; otherwise, the comparison is meaningless.

Prepare the same test objects

Use the same origin server, cache rules, and files for each candidate CDN:

• A real page or HTML file;

• A commonly used small static asset;

• A public test file of fixed size, such as 5 MB to 20 MB;

• If the business requires it, add images, video chunks, or API endpoints.

Do not test only the homepage. The homepage may contain dynamic content and third-party scripts, making it hard to tell where the slowness is; do not test only a fully cached small static file either, because it cannot represent origin fetch and large file throughput.

Separate cold cache from warm cache

The first request triggers an origin fetch, while subsequent requests may hit the edge cache directly; the two results should not be averaged together.

• Cold cache tests are used to observe the origin fetch path and first visit;

• Warm cache tests are used to observe edge node delivery capability;

• Dynamic requests should be evaluated separately for connection reuse, origin latency, and error rate.

Keep sample sizes for each test unit similar

'Shanghai China Telecom tested 500 times, Chengdu China Mobile tested only 3 times' is not suitable for direct comparison. Each core region and carrier combination should use a similar sampling frequency as much as possible and cover weekdays, weekends, and business peak hours.

You can first useCDNChart website speed testto observe access differences across regions and lines, then verify with server logs or real user monitoring.

Public probes are suitable for discovering problems horizontally, while real user data is closer to the final experience; the two should not replace each other.

Each test record should retain at least these fields:

测试时间、地区、城市、运营商、解析IP、节点ASN、HTTP状态码、
DNS耗时、TCP耗时、TLS耗时、TTFB、总耗时、下载速度、
缓存状态、文件大小、测试URL

When testing, control request frequency, use your own domain or an authorized test target, and do not turn speed testing into unauthorized stress testing.

After seeing speed test results, how do you determine where the problem is?

If a domain resolves to different IPs on different networks, this is a common phenomenon of CDN intelligent scheduling and should not be directly judged as a fault.

You can useCDN detection toolto check the domain's CNAME, node IPs, and possibly used CDN, then combine resolution results from various locations to determine whether there is abnormal scheduling.

Beyond performance, confirm these conditions before purchasing

Passing speed tests is only the first round. During formal selection, the following should also be included in the evaluation table:

• Service regions, mainland China access, domain ICP filing, and content compliance requirements;

• How SLA is defined, how availability is calculated, and how failures to meet commitments are handled;

• Actual costs billed by traffic, peak bandwidth, request count, HTTPS, and other items;

• Cache rules, refresh and preheating speed, origin policies, and log visibility;

• Whether monitoring data can be viewed by province and carrier;

• WAF, DDoS protection, access control, and certificate management capabilities;

• Technical support response speed during failures;

• Whether multi-CDN scheduling or a backup plan is needed, and whether switching is sufficiently controllable.

In particular, clarify log and monitoring granularity. Even if a CDN performs well at present, if after launch it cannot break down problems by region, carrier, and status code, future troubleshooting costs will still be high.

FAQ

If most users are in mainland China, must I choose a domestic CDN vendor?

Not necessarily. You should compare candidate vendors' actual service capabilities in mainland China, access conditions, line coverage, compliance requirements, cost, and support capabilities, rather than looking only at where the brand is registered. The final decision should still be based on test results for real regions and carriers.

Does a CDN with more nodes always mean faster speeds?

Not necessarily. Node count does not reflect node capacity, deployment locations, carrier interconnection, scheduling accuracy, or peak load.

Rather than asking 'How many nodes are there?', ask 'Where will my core users be scheduled, and what are the peak-hour P95 and availability?'

Why can't we look only at national average latency?

National averages dilute local problems. If a core carrier is slow, it may be pulled back to a seemingly normal average by many other fast samples.

At minimum, break down by region and carrier, and observe P50, P95, and availability at the same time.

Do tests need to cover all provinces?

Usually not in the first round. First cover core user regions and representative points in the seven major regions, then expand based on anomalies and complaints.

Province-wide coverage is better suited for continuous monitoring after launch, rather than investing the same resources evenly in every initial screening.

If the budget is limited and only a few points can be tested first, how should they be chosen?

Start with the three cities with the highest traffic or business value, and test China Telecom, China Unicom, and China Mobile separately in each city; then add a representative point farther from the core market, such as a city in Northwest, Northeast, or Southwest China, to observe cross-region scheduling and tail performance.

If you do not even know clearly where your real users mainly come from, first organize the last 30 days of logs, then doCDN vendor comparisonor useCDN selection recommendations. This step is usually closer to a reliable choice than running dozens more directionless speed tests.