How to Test Website Speed and Identify Slow Regions with CDNChart

Just because a website opens in one second for you does not mean all users can get the same access speed.

A site owner in Shanghai using China Telecom broadband may be accessing a CDN node near Shanghai; a China Mobile user in Heilongjiang, a China Unicom user in Guangdong, or an overseas user in Singapore may hit different nodes, routes, and responding IPs. Refreshing a few times on your own computer can at best prove that “access on the current network is working normally”; it cannot tell you which regions across the country are slow.

A more effective website speed testing method is to have monitoring points in different regions and on different carriers request the same domain at the same time, then compare HTTP status codes, responding IPs, DNS lookup time, connection time, download time, total time, and failed nodes.

CDNChartIts website speed test feature is designed around this scenario: after entering a domain, you can view access results separately for China Telecom, China Unicom, China Mobile, and monitoring points in Hong Kong, Macao, Taiwan, and overseas, and narrow down the issue by region, carrier, and response phase.

What exactly should a website speed test measure?

“Website speed” is not a single time figure.

From the moment a user enters a URL to the moment the website content is received, at least the following steps occur:

1. DNS resolves the domain name to an IP address;

2. the browser establishes a network connection with the target IP;

3. an HTTPS website completes the TLS handshake;

4. the CDN node or origin server processes the request;

5. the server starts returning content;

6. the client downloads the response data;

7. the browser parses HTML and loads images, CSS, and JavaScript;

8. the page finishes rendering and becomes interactive.

Therefore, the “total time” reported by different speed test tools may not refer to the same metric.

CDNChart’s current website speed test is mainly used to observe the HTTP access path of a domain, including monitoring points, carriers, responding IPs, IP locations, HTTP status, DNS lookup time, connection time, download time, total time, redirects, and access failures. It is suitable for answering questions such as “which region is slow,” “which carrier is abnormal,” and “whether traffic is being scheduled to different nodes,” but it is not equivalent to a full browser page rendering test.

MDN’snavigation and resource loading timingdocumentation also breaks DNS lookup, connection, request, response, and browser loading into multiple phases, showing that page performance cannot be judged by a single total time.

Practical steps for website speed testing with CDNChart

Step 1: Confirm the domain to test

Openthe CDNChart Website Speed Test tooland enter the domain that actually serves external traffic, for example:

www.example.com

Do not assume you should test only the apex domainexample.com. Many websites redirect the apex domain elsewherewww, or place different content on different subdomains:

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

These subdomains may use different CDNs, cache rules, and origin fetch configurations. A fast homepage does not mean the image, API, and download domains are also fast.

Before testing, it is best to determine which domain users actually access. If the issue is concentrated in image loading, test the image domain; if users report slow logins, check the domains used by the login page and API.

Step 2: Choose a monitoring scope that matches your user distribution

CDNChart currently provides monitoring categories for China Telecom, China Unicom, China Mobile, and Hong Kong, Macao, Taiwan, and overseas.

If your website users are mainly from mainland China, do not select only one “nationwide” average result; review the three major carriers separately. A website may show:

• China Telecom access is normal, while China Mobile is noticeably slower;

• faster in East China, slower in Northeast and Northwest China;

• normal domestically, with timeouts in some overseas countries;

• IPv4 routes are normal, while IPv6 access is abnormal on some networks;

• some regions resolve to different CDNs or cloud providers.

For websites serving overseas users, prioritize the countries where real users are located or nearby regions. If target users are in Japan and Singapore, testing only US nodes—even if results are good—cannot represent their actual experience.

Step 3: Start the test and review the overall results first

After the test completes, do not immediately focus on a single fastest node. First review four overall data points:

• fastest node;

• slowest node;

• average time;

• number of failed nodes.

The fastest result only proves that the website performs well under one set of conditions. What usually deserves attention is the slowest region, regions with repeated failures, and results from the same carrier that deviate significantly from other nodes.

Average time can also mask problems. For example, most nodes may be around 1 second while a few exceed 8 seconds; the average may still look acceptable, but users in affected regions are already having a poor experience.

Therefore, website speed testing should focus on finding “clusters of anomalies” rather than simply comparing a single lowest number.

How can you tell which regions a website is actually slow in?

Once the results are available, assess them in the order of region — carrier — responding IP — latency phase.

Filter by carrier first

Review China Telecom, China Unicom, and China Mobile results separately, and compare the same carrier across different regions.

If China Mobile nodes are generally slow while China Telecom and China Unicom are basically normal, the issue may be related to China Mobile routes, CDN scheduling for China Mobile users, or the relevant edge nodes. Do not simply attribute it to server performance, because the same server does not show the same problem for other carriers.

If all three major carriers are slow in a region, the issue is more likely related to:

• no suitable edge node in that region;

• DNS directing users to a distant region;

• a long origin fetch path from the local node;

• the domain not having effective coverage in that region;

• fluctuations in the website itself or the origin server during the test.

Then check whether anomalies are concentrated by region

An occasional slow node in a single test does not necessarily mean the entire region has a problem. Home broadband routes, test node load, and temporary network jitter can all cause anomalies.

The following patterns are more worth investigating:

• multiple nodes in the same province are slow at the same time;

• similar latency appears in adjacent regions;

• one carrier is consistently slow across multiple provinces;

• timeouts occur across multiple consecutive test rounds in the same region;

• slow nodes are concentrated on the same responding IP;

• performance is noticeably slower during weekday peak hours than during the day.

In such cases, repeat the test at different times rather than switching CDNs based on a single result.

CDNChart’s publicly availabletest methodology and scoring criteriaalso note that website speed test results can be affected by target site fluctuations, rate limiting, and temporary network jitter. Speed test data is useful for identifying problems and establishing baselines, but it should be interpreted alongside sample size, test timing, and real business monitoring.

How should each metric in the test results be interpreted?

HTTP status code: first confirm whether the website was actually accessed successfully

Speed is meaningless if the page returns an error.

Common statuses include:

• 200the request returned normally;

• 301or302a redirect occurred;

• 403may be blocked by WAF, access control, or regional policies;

• 404the requested content does not exist, or the origin Host configuration may be incorrect;

• 429the request rate is limited;

• 502or503or504may involve CDN node, origin fetch link, or origin server anomalies.

If only some regions return 403 while other regions return 200, check WAF regional policies, bot protection, and access allowlists. If 5xx errors are concentrated in multiple regions, further verify CDN logs and origin status.

Responding IP: determine where users are being scheduled

The responding IP helps determine whether different regions are connecting to the same node or network.

For example, if nodes in South China, East China, and Northeast China all resolve to the same responding IP, scheduling may be too concentrated; if a slow region hits a different IP from other regions, you can further check the network, route, and node status corresponding to that IP.

Note, however, that the location shown by an IP database is not necessarily the exact physical location of the server room. Anycast, IP broadcasting, registered addresses, and actual traffic entry points may differ.

A more reliable approach is to observe the responding IP together with DNS lookup time, connection time, carrier, and results from multiple test rounds.

DNS lookup time: the domain is already slow before the connection

A high DNS lookup time usually means waiting for the DNS result takes longer. Possible causes include:

• an overly long CNAME chain;

• unstable authoritative DNS responses;

• recursive DNS cache misses;

• cross-border DNS queries;

• DNSSEC validation or upstream query time;

• different recursive resolvers used in different regions;

• an overly complex DNS scheduling policy.

If DNS lookup time is high in many regions, check DNS and CNAME chains first; if it is high only for certain carriers, it may be related to the local recursive DNS or scheduling results.

Connection time: focus on node distance and network quality

Connection time mainly reflects the cost of establishing a network connection between the client and the responding IP.

If connection time is generally high, it may indicate:

• users are scheduled to distant nodes;

• cross-carrier or cross-border access;

• route detours;

• network packet loss causing handshake retransmissions;

• insufficient connection handling capacity at edge nodes;

• differences between IPv4 and IPv6 access paths.

If DNS lookup is fast but connection time rises significantly in a region, the investigation should shift away from DNS to the responding IP, node location, and network routes.

Download time: not only related to server speed

Download time is affected by response size, network throughput, node load, and cache status.

Slow downloads for small files may be due to poor connection quality, slow node processing, or waiting for origin fetches; for large files, check sustained throughput, service bandwidth, congestion, and rate limiting.

When comparing download time, use the same domain, the same resource, and similar test times. Do not directly compare a 3 KB icon with a 20 MB installer package.

Total time: use it to spot anomalies, not as a substitute for phase analysis

Total time is the most intuitive metric, but it only tells you whether the request is fast overall and cannot by itself show where it is slow.

Redirects, repeated connections, DNS queries, network transmission, and server-side processing can all be included in total time. When total time is high, continue checking:

• whether DNS lookup time is abnormal;

• whether connection time is abnormal;

• whether the download phase accounts for too high a proportion;

• whether one or more redirects occurred;

• whether the HTTP status is normal;

• whether the result hit a different responding IP from other nodes.

Do not insist that the phase figures must add up exactly to total time. Tool measurement boundaries, redirects, and protocol handling may differ.

How should common speed test results be interpreted?

This table can only be used to determine the direction of investigation, not as a final fault conclusion. For example, if all regions are slow, it may be an origin performance issue, the test resource itself may be large, or the request may have undergone multiple redirects.

Use curl to supplement the access path test locally

After multi-region speed testing identifies the problem area, use curl on your own computer or a server in the target region for additional checks:

curl -o /dev/null -sS \
  -w 'status=%{http_code}\nremote_ip=%{remote_ip}\ndns=%{time_namelookup}s\nconnect=%{time_connect}s\ntls=%{time_appconnect}s\nttfb=%{time_starttransfer}s\ntotal=%{time_total}s\nredirects=%{num_redirects}\n' \
  https://www.example.com/

Focus on:

• statusthe final HTTP status code;

• remote_ipthe actual responding IP connected to;

• dnscumulative time from request start to DNS resolution completion;

• connectcumulative time from request start to TCP connection completion;

• tlscumulative time from request start to TLS handshake completion;

• ttfbcumulative time from request start to first byte received;

• totaltotal time for the entire request;

• redirectsnumber of redirects.

Most of these fields are cumulative times. To estimate a specific phase, subtract one from another; for example, the TCP connection phase is approximately:

time_connect - time_namelookup

The TLS phase is approximately:

time_appconnect - time_connect

curl’s official--write-outdocumentationlists these timing variables and output methods, making it suitable for using the same command across different servers to establish comparisons.

CDNChart and curl serve different purposes: CDNChart is for observing multiple regions and carriers at the same time, while curl is for verifying a specific device, a specific network path, and more detailed protocol phases.

Why also pay attention to TTFB and full page load?

CDNChart’s current results can help break down DNS lookup, connection, download, and total time, but website slowness does not necessarily occur only in these phases.

TTFB is the wait time from request start to receipt of the first response byte. It may include DNS, connection, TLS, CDN processing, cache and origin fetch, and origin response.web.devalso points out that TTFB is the foundation for subsequent page metrics, but it should be understood in the context of how content is delivered under different website architectures, and a single fixed threshold cannot be used in isolation to judge all websites.

If CDNChart shows that network requests are fast in all regions but users still find the page slow, continue using browser developer tools to check:

• whether above-the-fold images are too large;

• whether JavaScript blocks rendering;

• whether CSS and fonts load slowly;

• whether the page requests many third-party domains;

• whether the LCP element is discovered very late;

• whether the main thread executes scripts for a long time;

• whether complex client-side rendering occurs after the API returns.

At this point, the question is no longer just “which regions is the website slow in,” but “why does the browser take so long to display content after receiving it?”

One speed test is not enough—how do you establish reliable results?

Website speed testing must control at least four variables: test target, test region, test time, and cache status.

It is recommended to keep records as follows:

测试时间：
测试域名：
测试资源：
目标用户地区：
运营商：
响应IP：
HTTP状态码：
解析时间：
连接时间：
下载耗时：
总耗时：
失败节点：
是否发生重定向：
当时是否处于业务高峰：

When onboarding a CDN, use the same domain or a test resource of comparable size before and after the switch, and compare the same regions and carriers. When the website fluctuates, cover daytime, evening peak, and weekends rather than choosing only the single best-performing result.

When choosing a speed test platform, also confirm whether the tool truly covers the regions where target users are located, distinguishes carriers, and displays responding IPs and phase-by-phase timing.Website speed test tool comparisonandCDN test node and metric selectionThe core difference between them also lies in the fact that different tools do not answer exactly the same questions.

Frequently asked questions

How can website speed testing be more accurate?

Use the same domain or resource, test repeatedly from different regions and carriers, and observe the status code, responding IP, DNS lookup time, connection time, download time, total time, and failed nodes separately. Cover at least the regions where real users are located and business peak hours.

Why does the site open quickly for me but the speed test shows it is slow elsewhere?

You and users elsewhere may use different carriers, recursive DNS, network routes, and CDN nodes. Your own access result represents only your current device and current network, not users nationwide.

Should website speed testing use the homepage or a static file?

To troubleshoot overall access, test the main domain first; to troubleshoot CDN caching and node transmission, also test a representative static resource domain. If images, downloads, APIs, and the main site use different subdomains, test them separately.

If average time is normal, does that mean the website has no problems?

Not necessarily. Averages can hide severe timeouts in a small number of regions. Continue checking the slowest nodes, failed nodes, and whether anomalies are concentrated in the same region or carrier.

If the responding IP location is far from users, does that mean CDN scheduling is wrong?

Not necessarily. IP database records are not the same as the exact physical location of a node, and Anycast addresses may be advertised from multiple locations. Judge in combination with connection time, routing, carrier, and multiple test rounds.

Why do results for the same website differ each time the speed test is run?

DNS caching, CDN scheduling, cache hits, network congestion, node load, and origin server fluctuations can all affect results. Slight changes are normal; anomalies that consistently concentrate in the same region, carrier, or responding IP are more worth investigating.

Can CDNChart speed testing measure a page’s LCP and JavaScript execution time?

The current website speed test mainly observes domain HTTP access, responding IPs, and network phase timing; it is not equivalent to a full browser rendering test. LCP, INP, script execution, and page resource waterfalls require browser developer tools or real user monitoring.

After finding that some regions are slow, should I switch CDNs immediately?

It is not recommended. First confirm whether the problem can be reproduced, then determine whether the slowness is in DNS, connection, download, origin fetch, or front-end rendering. CDNChart is suitable for identifying regional differences and establishing baselines, but before ultimately switching CDNs, you should still complete tests with real business URLs, vendor trials, or a POC.