Why should online website speed tests use the user's region? Choosing the wrong node can make the results meaningless

When testing a website’s speed online, many people choose the node “closest to the server.”

If the server is in Hong Kong, they select Hong Kong; if it is in the US, they select Los Angeles; if the company is in Shanghai, they only test Shanghai Telecom. The result looks fast, so they conclude the website is fine.

But real users may mainly be in Beijing, Chengdu, or Harbin, and may use China Mobile or China Unicom. The DNS resolution, ISP routes, CDN scheduling, and cross-border paths they actually traverse are often completely different from the test node selected by the site owner.

So the most important principle for online website speed testing is not “choose the region closest to the server,” but:

Prioritize the regions and ISPs where real users are located, then use the server location or CDN node location as a reference.

A test node represents the visitor, not the server. If the node is wrong, even highly accurate DNS resolution time, connection time, download time, and total time may have little to do with real users.

Why does the same website’s speed change when you switch regions?

When a user visits a website, the browser does not send traffic over one fixed path directly to the server. The request may pass through at least:

用户设备
→ 本地网络
→ 运营商
→ 递归DNS
→ CDN调度
→ 边缘节点
→ 回源网络
→ 源站

As soon as the test region or ISP changes, any one of these stages may change.

For example:

• China Telecom in Beijing and China Mobile in Guangzhou use different recursive DNS resolvers;

• The CDN may route users in East China to a Shanghai node and users in Southwest China to a Chengdu node;

• There may be cross-network access between a given ISP and a CDN node;

• Overseas users may traverse cross-border links;

• IPv4 and IPv6 may hit different entry points;

• A region may lack a suitable node, forcing access to a more distant data center;

• The same CDN node may have different link quality on different ISPs.

Therefore, fast results from Shanghai Telecom do not prove that Guangzhou Mobile is also fast; normal results from a US node do not mean users in mainland China have normal access.

User region matters more than server region

Where the server is located determines the origin fetch distance for cache misses and dynamic requests; where users are located determines the first half of the path from users to the CDN node or origin.

If a website does not use a CDN, the distance between users and the server usually directly affects connection latency. If it does use a CDN, user location still matters because the CDN must schedule users to appropriate edge nodes based on region and network.

The two types of tests can be understood as:

Test results from the server region are suitable for diagnosis, but should not replace results from user regions.

Suppose the origin is in Singapore and users mainly come from Indonesia, Japan, and Australia. Testing only from Singapore may prove only that access near the server data center is normal; what actually determines business experience is which nodes users in Jakarta, Tokyo, and Sydney hit, whether their connections take circuitous routes, and how dynamic requests are fetched from the origin.

Why should website speed tests in mainland China also distinguish between ISPs?

Selecting a city alone is not enough; you also need to consider China Telecom, China Unicom, and China Mobile.

Different ISPs in the same city may have completely different routes, interconnection exits, and CDN nodes. For example:

• China Telecom Beijing connects to a Beijing node;

• China Unicom Beijing connects to a Tianjin node;

• China Mobile Beijing connects to a Shanghai node;

• Although the three ISPs hit the same IP, their actual network paths differ.

This is also why a “nationwide speed test” cannot rely only on a single national average. When users are mainly from mainland China, you should at least observe China Telecom, China Unicom, and China Mobile separately in core regions.

In the CdnChart website speed test tool, you can filter monitoring results by China Telecom, China Unicom, China Mobile, Hong Kong/Macau/Taiwan, and overseas, and view response IP, IP location, HTTP status code, DNS resolution time, connection time, download time, total time, redirects, and failed nodes.

Looking only at the national average can produce situations such as:

电信：整体正常
联通：整体正常
移动：多个地区明显偏慢
全国平均：看起来还能接受

The average is not wrong, but it masks the problems experienced by China Mobile users.

Overseas website speed tests cannot just select “overseas nodes”

“Overseas” is not a single network environment.

Tokyo, Singapore, Mumbai, Frankfurt, London, Los Angeles, and São Paulo differ significantly in network distance, ISP structure, and cross-border paths. A website that performs well in the US does not necessarily give users in Southeast Asia, Europe, and South America the same experience.

For overseas websites, arrange tests based on the countries where real users are located:

• If users are mainly in Japan, prioritize testing Japan;

• If users are mainly in Southeast Asia, cover actual markets such as Singapore, Indonesia, Vietnam, and Thailand;

• If users are concentrated in Europe, observe Western Europe, Central Europe, and major countries separately;

• If users are spread across North America, at least distinguish between the eastern and western US and Canada;

• If users are from mainland China but the server is overseas, also focus on testing mainland China’s three major ISPs and cross-border paths.

When there is no node in the target country, you can choose a nearby region with similar network distance and interconnection relationships as a substitute, but the conclusion must retain its limitations; speed test results from a neighboring country cannot be directly equated with real user experience.

How can you determine the real user regions for a website?

Do not choose test nodes based on intuition. The most reliable basis comes from the website’s own traffic and business data.

You can compile user distribution from the following sources:

• Website access logs;

• CDN access logs;

• Web analytics platforms;

• API gateway logs;

• Order shipping regions;

• Registered user regions;

• Countries of paying users;

• Customer support feedback;

• Data reported by mobile apps or clients.

Regional weighting does not necessarily have to be based only on traffic volume.

A country may have low traffic but many paying users; a region may have high traffic but mostly bots and invalid requests. Therefore, when selecting test regions, you can also consider:

地区优先级 = 用户数量 + 收入贡献 + 业务重要性 + 故障风险

This is not about calculating a fixed formula, but about avoiding choosing nodes based solely on page views.

Use a three-tier approach to plan test regions

If users cover a wide area, you can divide test regions into three tiers.

Core regions

Core regions usually contribute the majority of users, revenue, or key business, and should be covered in depth:

• Major provinces or countries;

• Major ISPs;

• Daytime and evening peak hours;

• Home pages, static resources, and core APIs;

• Multiple repeated test rounds;

• Real user monitoring.

Failure rates and long-tail latency in core regions are usually more important than the fastest results in non-core regions.

Representative regions

There is no need to test every city, but you can select regions that represent different network environments.

In mainland China, you can cover North China, East China, South China, Central China, Southwest China, Northwest China, and Northeast China, and distinguish the three major ISPs in key areas. Overseas, you can select countries or regional hubs based on target markets.

Representative regions are used to identify regional issues, such as:

• East China is generally normal, while Northeast China is generally slow;

• Southeast Asia is fast, while South America is noticeably slow;

• China Telecom and China Unicom are normal, while China Mobile has cross-region anomalies;

• Domestic access is normal, while some nodes in Europe time out.

Edge regions

Edge regions have fewer users, but they can be used to observe the worst access paths, global reachability, and the scope of failures.

Such results may not carry the highest business weight, but they can help identify:

• TLS failures in some countries;

• DNS resolution failures in certain regions;

• WAF mistakenly blocking overseas requests;

• Incomplete IPv6 paths;

• Obvious gaps in CDN coverage;

• Severe circuitous routing of origin fetches in a distant region.

Which URLs should be selected for online website speed tests?

After choosing the right regions, you also need to choose the right test targets.

Testing only the home page is not enough, because different content on a website may use different domains, CDNs, and caching policies.

At a minimum, prepare the following targets:

If images, JavaScript, downloads, and APIs use different subdomains, test them separately.

For example:

www.example.com
static.example.com
img.example.com
api.example.com
download.example.com

Normal main site speed does not mean that all other resource domains are normal.

Which metrics are most useful when testing speed in different regions?

HTTP status codes and failed nodes

First determine whether the request succeeded.

If some regions return 200 while others return 403, 429, 502, 503, 504, or time out, the problem is no longer just “slightly slow speed” but differences in regional availability.

If overseas nodes consistently return 403, check WAF regional policies, bot protection, and access controls; if a specific ISP consistently times out, check node scheduling and routes.

Response IP

The response IP can help determine where different users are scheduled.

If slow nodes are concentrated on the same response IP, the problem may be related to a specific edge node or route; if different regions connect to completely different networks, regional scheduling, multi-CDN, or active-standby failover may be involved.

However, the location of the response IP cannot be directly equated with the node’s precise physical location. The IP registration address, database-inferred location, and actual network entry point may differ.Different CDN node IPs returned in different regionsThis is a common phenomenon and should be interpreted together with the ISP and connection time.

DNS resolution time

High DNS resolution time may involve recursive DNS, authoritative DNS, CNAME chains, and cross-border queries.

If DNS resolution is slow in all regions, check the domain configuration and authoritative DNS; if it is slow only in a certain country or ISP, the cause may be local recursive DNS, the scheduling chain, or network access.

Connection time

Connection time mainly reflects the network distance, routing, and packet loss between the user and the target IP.

If DNS resolution is fast in a region but connection time is noticeably high, the problem usually occurs after resolution. In this case, check the response IP, node distance, cross-ISP access, IPv4/IPv6 paths, and network routing.

Download time

Download time is affected by resource size, node throughput, link congestion, and cache status.

Image sites, download sites, and video services cannot rely only on small-file tests. Small files are good for observing latency; large files are more likely to reveal sustained throughput and bandwidth limits.

Total time and redirects

Total time is useful for quickly spotting anomalies, but it cannot explain the cause on its own.

If total time is high in a region, break it down further into DNS resolution, connection, and download stages, and check whether multiple 301 or 302 redirects occur. Cross-domain redirects may also repeat DNS, connection, and TLS processes.

Why can data center speed tests differ from real user experience?

Many online speed test nodes are deployed in cloud servers, VPSs, or edge function environments, where network quality is usually more stable than on home broadband and mobile networks.

Real users may use:

• Home broadband;

• 4G or 5G;

• Corporate proxies;

• Campus networks;

• Public Wi-Fi;

• Low-end phones;

• Cross-border networks;

• VPN connections.

Therefore, active probes are suitable for comparing regions and ISPs under consistent conditions, but they cannot fully replace real user monitoring.

In its article on the difference between lab data and field data, web.dev points out that lab data comes from preset devices and network environments, while field data comes from real users’ devices, networks, and locations. The two observe different angles and should be used together.

A more reliable process is:

多地区主动测速发现异常
→ 按国家和运营商缩小范围
→ 检查DNS、响应IP和耗时阶段
→ 使用真实用户数据确认影响
→ 结合CDN与源站日志定位原因

Should test nodes be close to users or close to CDN nodes?

For user-experience testing, prioritize the user’s region; for troubleshooting, add reference tests near CDN nodes and near the origin.

The three types of nodes serve different purposes:

• User-region nodes: assess real access experience;

• Near CDN nodes: assess whether edge services themselves are functioning normally;

• Near the origin: assess whether origin processing and the local network are functioning normally.

For example, if access is slow in the user region but fast near the CDN node, the problem may lie in the route between users and the node; if both the user region and near the CDN node are fast but dynamic pages are still slow, continue checking origin fetches and origin processing.

Do not treat fast results from diagnostic nodes as proof that user experience is normal.

What if there is no speed test node in the user’s city?

When there is no exact city match, you can select in the following order:

1. Same city, same ISP;

2. Same province, same ISP;

3. Adjacent province or same region, same ISP;

4. Major network nodes in the same country;

5. Neighboring countries with similar network distance and interconnection relationships;

6. Real user monitoring or supplementary testing from local servers.

When selecting a substitute node, note in the record that it is only a representative sample.

For example, if there is no node in a small Southeast Asian city, you can first choose a major city in that country; if there is no node in that country either, choose a neighboring region, but do not directly declare that the results represent the entire country.

Once the regions are chosen correctly, how should the results be interpreted?

You can quickly classify them using the following patterns:

If a problem occurs only once, repeat the test first. Only anomalies that persist in the same region, ISP, or response IP are more worthy of entering a formal troubleshooting process.

Final checklist before speed testing

Before starting an online website speed test, confirm the following:

• Test regions are based on real user distribution, not the server location;

• Core mainland China markets are separated by China Telecom, China Unicom, and China Mobile;

• Overseas tests are broken down by target country or region;

• Home pages, static resources, dynamic pages, and APIs are not mixed into a single test target;

• Multiple test rounds use the same domains and resources;

• Response IP, status code, DNS resolution, connection, download, and total time are recorded;

• Whether slow nodes are concentrated in a certain region, ISP, or response IP;

• Tests cover normal periods and business peak hours;

• Active speed test results have been cross-validated with real user data;

• A single fastest result is not used in place of an overall assessment.

If you have not yet compiled user distribution, start by identifying the countries, provinces, and ISPs with the highest traffic in your access logs, then useNode coverage and metrics of website speed test toolsFilter for suitable testing methods.

The purpose of an online website speed test is not to get a flattering number, but to answer a more specific question: for the people who actually use the website, is access from their regions and networks fast and stable, and which part of the access path is slow?