How to Test Domain Speed with CdnChart: Measuring Domain Access Speed and Network Latency

A website opening normally on your own computer does not mean users across the country can access it normally.

For the same domain, accessing it from Beijing Unicom, Guangzhou Mobile, Chengdu Telecom, and Singapore may resolve to different IPs, traverse different network paths, and ultimately reach different CDN nodes. Some websites take only a few hundred milliseconds on China Telecom's network but may connect slowly on China Mobile; some have low Ping latency but still take two or three seconds when an HTTPS request is actually made.

This is why a domain speed test cannot rely on opening the site once on your local machine or running Ping only once.

The point of using CdnChart for a domain speed test is not to get a simple 'speed score,' but to access the same domain simultaneously from different regions and carriers, then compare their response IPs, HTTP status codes, resolution time, connection time, download time, total time, and failures. This shows which regions and carriers are affected and at which stage of the access path the problem occurs.

What a Domain Speed Test Actually Measures

The term 'domain speed test' is often understood as pinging the domain. In reality, Ping latency and website access speed are not the same metric.

Ping primarily sends ICMP Echo Requests and waits for replies to check IP-layer reachability and round-trip time. Microsoft'spingofficial documentation for the command also describes verifying IP-layer connectivity and displaying ICMP echo replies and round-trip times.

A real website visit also involves:

1. Resolving the domain name to an IP;

2. Establishing a connection with the server or CDN node;

3. Completing TLS negotiation for HTTPS websites;

4. Sending the HTTP request;

5. The CDN or origin server processing the request;

6. Receiving HTML, images, or other content;

7. The browser continuing to load and render page resources.

Therefore, a domain speed test covers at least two different layers:

If you only need to gauge basic network round-trip time, use Ping. To confirm whether users in different regions can open the website normally, you need a multi-node HTTP speed test. If the main document is fast but the page still feels slow, continue by reviewing the browser request waterfall.

Where to Find the CdnChart Domain Speed Test

Open CdnChart'swebsite speed test tool, enter the domain you want to test in the input box, for example:

www.example.com

Enter the domain in the format shown in the page's input box; you do not need to substitute a test IP for the domain. Requesting an IP directly may bypass DNS scheduling and may also produce incorrect results because the HTTPS certificate and Host do not match.

The page currently provides the following node filters:

• 
  Select all;
  

• 
  China Telecom;
  

• 
  China Unicom;
  

• 
  China Mobile;
  

• 
  Hong Kong, Macao, Taiwan, and overseas.
  

As of 14:03:57 on September 26, 2026 shown on the page, the platform displays a sample of 350 monitoring points and 4 carrier categories. 'Monitoring point samples' here is the platform's current page statistic and does not mean every test will have successful responses from all nodes; the actual number participating is also affected by node status, target restrictions, timeouts, and other factors.

Step-by-Step CdnChart Domain Speed Test

Step 1: Define what this test needs to solve

Even when testing the same domain, different goals require different node selections and ways of interpreting results.

If users report that 'the site won't open on mobile networks,' focus on China Mobile nodes while keeping some China Telecom and China Unicom nodes as controls.

If you are preparing to change CDNs, select all nodes and compare before and after migration using the same domain, a similar time window, and the same test scope.

If the website mainly serves overseas users, select Hong Kong, Macao, Taiwan, and overseas nodes, and focus on whether the target country succeeds, whether the response IP is reasonable, and whether cross-region scheduling is occurring.

Common test goals map to the following:

Clarifying the problem first prevents you from seeing a set of speed test results without knowing what to compare.

Step 2: Enter the domain users actually access

Test the domain users actually visit, not just the origin IP. For example, if the website's public entry point is:

www.example.com

do not test only:

203.0.113.10

Domain access may go through smart DNS, a CDN, a WAF, or a reverse proxy; testing the IP directly bypasses some of these layers. Even if the result is fast, it does not mean users accessing the site through the domain will be just as fast.

Also distinguish between subdomains. The following addresses may use completely different infrastructure:

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

The main site may go through a CDN, the API may connect directly to a cloud load balancer, and the download domain may use another CDN. A single test of the main domain cannot replace testing all business entry points.

Step 3: Select regions and carriers

For the first test, use 'Select all' to observe the overall distribution. After getting results, narrow the scope and retest the anomalous carrier.

Do not focus only on the fastest node. The value of a domain speed test often comes from anomalous nodes, for example:

• 
  China Telecom and China Unicom are normal, but China Mobile is generally slow;
  

• 
  East China is normal, but connection time in Northeast China increases significantly;
  

• 
  Mainland China is normal, but some overseas nodes return 403;
  

• 
  Most nodes resolve to the CDN, but a few still access the old IP;
  

• 
  Most nodes return 200, but 502 errors cluster in one region;
  

• 
  Results on the same carrier vary widely.
  

If you look only at the national average, these issues are easily hidden.

Step 4: Wait for the test to complete, then review the overall results

After the test, start with the fastest node, slowest node, average time, number of participating nodes, and number of failures.

There are two principles for interpretation.

First, averages are only suitable for a quick overview of overall performance and cannot replace node details. A particularly slow region may account for only a small sample and have limited impact on the average, but the experience for users in that region is already unacceptable.

Second, the fastest node usually does not represent most users. It may be close to the server, happen to hit a warm cache, or use a higher-quality data center network. Focus more on typical results in core user regions and on whether anomalies recur.

If users often report that the website alternates between fast and slow, refer to the published'How to Choose a CDN Speed Test Site? Start by Checking Nodes, Metrics, and Result Records'to establish a consistent testing time, node set, and result-recording method.

How to Read Each Item in Domain Speed Test Results

Test node

The test node indicates where the request originates. Mainland China nodes usually also indicate the carrier, such as China Telecom, China Unicom, or China Mobile.

When interpreting results, start with the regions where real users are located. For example, if the main customers come from Guangdong Mobile, do not look only at Beijing Telecom results. Even when both access the same domain, they may resolve to different CDN nodes and take different network paths.

Some nodes may also be labeled as residential or VPS. Data center nodes are usually more stable but cannot fully represent ordinary home broadband; residential networks are closer to real users but may fluctuate more.

Response IP

The response IP is the address the test node ultimately connects to when accessing the domain. It helps assess DNS scheduling and CDN node distribution.

If a website using a CDN returns multiple IPs in different regions, this is usually not abnormal; the CDN may schedule by region and carrier. What really needs attention is:

• 
  Some regions return the origin IP;
  

• 
  After CDN migration, the old provider's IP is still returned;
  

• 
  Many regions resolve to a distant region;
  

• 
  All failed nodes point to the same response IP;
  

• 
  IPv4 and IPv6 paths perform very differently.
  

IP location is only a database inference and does not necessarily equal the server's exact physical location. Anycast addresses may also use the same IP in multiple countries or regions, so you cannot declare node scheduling incorrect based solely on IP geolocation.

IP location

IP location helps identify obvious anomalies, such as mainland Chinese users being scheduled to addresses in Europe or the United States, or users in South China concentrated on North China nodes.

However, geographic proximity does not necessarily mean the best network path. Two networks that appear to be in the same city may detour because of carrier interconnection; an IP registered elsewhere may also be accessed locally via Anycast.

More reliable judgment should combine:

• 
  IP ownership;
  

• 
  Carrier or ASN;
  

• 
  Connection time;
  

• 
  Routing path;
  

• 
  Results from other nodes in the same region;
  

• 
  CDN response headers or provider console information.
  

HTTP status code

Status codes should be reviewed before speed numbers. If the request is not successful, low latency is meaningless.

Common results include:

If only one region returns 403, it is not necessarily a site-wide failure; it is more likely that the WAF or access rules restrict that node. If multiple carriers return 502 or 504 at the same time, further check CDN origin fetches and origin server status.

Resolution time

Resolution time is the time the test node spends completing domain resolution before initiating the HTTP connection.

If it remains high, check:

• 
  Whether the CNAME chain is too long;
  

• 
  Whether the authoritative DNS responds slowly;
  

• 
  Whether a carrier's recursive DNS is abnormal;
  

• 
  Whether the DNS record TTL is set unreasonably;
  

• 
  Whether IPv4 and IPv6 resolution differ;
  

• 
  Whether caches have not expired after a recent record change.
  

If only the first test resolves slowly and later tests are noticeably faster, DNS caching may be involved. If multiple nodes on the same carrier remain consistently high, further investigation is more worthwhile.

For a more complete DNS troubleshooting process, see the published'Will Slow DNS Resolution Slow Down a CDN? How to Troubleshoot Domain Resolution Time'.

Connection time

Connection time mainly reflects the process of establishing a connection between the test node and the response IP. It is affected by network distance, carrier interconnection, routing detours, packet loss, and target node status.

When the following patterns appear, interpret them as follows:

• 
  The same response IP differs greatly across carriers: possible carrier line issue;
  

• 
  Nodes corresponding to a certain response IP are generally slow to connect: possible node or routing issue;
  

• 
  Overseas nodes connect noticeably slower than local regions: possible lack of nearby nodes;
  

• 
  Connection time occasionally spikes: possible packet loss, congestion, or node fluctuation;
  

• 
  Connections are slow in all regions: check the target node, server region, and network entry point.
  

Fast connection does not guarantee a fast page. After the request reaches the CDN, it may still wait for origin fetches, application processing, and content download.

Download time

Download time is the time spent transferring the response content. It is related to response size, node bandwidth, link throughput, congestion, and rate limiting.

If resolution and connection are fast but download time is noticeably high, continue checking:

• 
  Whether the page or file is too large;
  

• 
  Whether compression is enabled;
  

• 
  Whether images are reasonably optimized;
  

• 
  Whether CDN node bandwidth is insufficient;
  

• 
  Whether download rate limiting is in place;
  

• 
  Whether large files support Range requests;
  

• 
  Whether the test content hits the CDN cache.
  

Content of different sizes cannot be compared directly. A 5 KB page and a 10 MB installation package, even on the same node, have no directly comparable download times.

Total time

Total time is the overall time from the start of the speed test request to completion. It is suitable for horizontal comparison but cannot explain the root cause alone.

For example, two nodes both have a total time of two seconds:

• 
  Node A may have slow DNS and connection but fast content download;
  

• 
  Node B may connect quickly but download content slowly.
  

The numbers are the same, but the optimization direction is completely different.

Therefore, when total time is high, go back to the resolution, connection, download, and redirect stages before drawing conclusions such as 'poor server performance' or 'the CDN node is no good.'

Redirects

Redirects add extra requests. Common chains include:

http://example.com
→ https://example.com
→ https://www.example.com
→ https://www.example.com/zh/

Every cross-domain or cross-protocol redirect may repeat DNS, connection, and TLS negotiation. A small number of necessary redirects is usually acceptable, but multi-layer redirects, redirect loops, or incorrect regional redirects can significantly increase total time.

During testing, confirm that the final domain matches expectations, and avoid seeing only the final 200 response while ignoring that several redirects occurred earlier.

Failed nodes

Failed nodes cannot simply be deleted or treated as 'no data.'

Failure itself is a result. It may indicate:

• 
  DNS resolution failure;
  

• 
  TCP connection timeout;
  

• 
  TLS certificate or protocol error;
  

• 
  WAF blocking the test node;
  

• 
  CDN node anomaly;
  

• 
  Origin server cannot be fetched;
  

• 
  The website allows access only from specific regions;
  

• 
  The target rate-limited detection requests within a short period.
  

An occasional failure on a single node can be retested later; concentrated failures on the same carrier or in the same region should be prioritized.

How to Determine Whether Domain Access Speed Is Normal

There is no fixed millisecond standard that applies to all websites.

Same-city static resources, cross-border dynamic APIs, and large file downloads should not use the same threshold. A more practical approach is to establish your own comparison baseline.

Compare with historical results for the same website

If the website's total time is usually stable within a certain range and rises noticeably after a new release or CDN change, performance may have degraded even if the result does not exceed a generic threshold.

Compare different carriers

Similar results across China Telecom, China Unicom, and China Mobile are usually better than one being especially fast and another especially slow. If the three networks differ greatly, further check CDN scheduling, line coverage, and response IPs.

Compare P50 and slow nodes

If the average is normal but the slowest nodes are poor, some users are still affected. For critical services such as login, payment, and APIs, tail latency is often more important than the best result.

Compare before and after CDN adoption

CDN acceleration results should be compared using the same domain, the same content, the same nodes, and a similar time window. Do not compare the pre-migration homepage with a small post-migration static file.

Test multiple times rather than just one round

A single test may be affected by DNS caching, node load, and temporary routing fluctuations. It is advisable to cover:

• 
  Weekdays and weekends;
  

• 
  Daytime and evening peak hours;
  

• 
  Cache HIT and MISS;
  

• 
  Before and after release;
  

• 
  During and after an incident.
  

What Is the Difference Between CdnChart Domain Speed Test and Ping?

Ping is suitable for checking basic reachability, ICMP round-trip time, packet loss, and latency variation. The CdnChart domain speed test initiates actual HTTP access from multiple regions and carriers and observes domain resolution, connection, status codes, response IPs, download, and total time.

The two are not substitutes.

If Ping is slow, website access may be affected by basic network distance, packet loss, or routing; if Ping is fast but HTTP total time is high, the problem may occur during TLS, server processing, CDN origin fetch, download, or page resource stages.

For the full distinction between the two, continue reading the published'Ping Is Fast but the Website Is Slow? Don't Mistake Latency for Load Speed'.

Use Ping to Check Network Latency

On Windows, run:

ping www.example.com

On Linux or macOS, you can specify the number of tests:

ping -c 20 www.example.com

Main things to check:

• 
  The IP resolved from the domain;
  

• 
  Minimum, maximum, and average latency;
  

• 
  Whether there is packet loss;
  

• 
  Whether latency fluctuates.
  

If the domain uses a CDN, Ping usually reaches the edge node returned by DNS, not the origin server. Some CDNs or servers restrict ICMP, so a Ping timeout does not necessarily mean HTTPS is unavailable.

Use curl to Break Down Domain Access Time

CdnChart is suitable for viewing differences across regions, whilecurlcurl is suitable for finer stage timing of a single HTTPS request from the current device:

curl -L -o /dev/null -sS \
  -w '状态码: %{http_code}\n响应IP: %{remote_ip}\nDNS完成: %{time_namelookup}s\nTCP完成: %{time_connect}s\nTLS完成: %{time_appconnect}s\n首字节: %{time_starttransfer}s\n总耗时: %{time_total}s\n下载大小: %{size_download} bytes\n下载速度: %{speed_download} B/s\n重定向次数: %{num_redirects}\n' \
  https://www.example.com/

curl's official manual defines these timing fields as follows:

• time_namelookup: from request start to completion of domain resolution;
  

• time_connect: from request start to completion of the TCP connection;
  

• time_appconnect: from request start to completion of the application-layer connection such as TLS;
  

• time_starttransfer: from request start to receipt of the first byte;
  

• time_total: total time required to complete the entire operation.
  

Most of these times are cumulative and cannot all be added together. For example,time_connectalready includes the preceding DNS time, andtime_starttransferusually also includes DNS, connection, TLS, and server wait time.

If you need to estimate individual stage times, you can subtract the previous cumulative value from the next cumulative value, but redirects, connection reuse, proxies, and HTTP/3 can make this calculation more complex.

Use MTR or Traceroute to Assess the Network Path

If a multi-node speed test finds that connection time in a certain region remains high, run MTR on the affected network:

mtr -rwzc 20 www.example.com

On Windows, you can also use:

tracert www.example.com

Key observations:

• 
  Whether the route detours significantly;
  

• 
  At which hop latency starts to rise continuously;
  

• 
  Whether the anomaly continues to later hops;
  

• 
  Whether IPv4 and IPv6 paths differ;
  

• 
  Whether the problem occurs at the local carrier, in cross-carrier interconnection, or near the target network.
  

An intermediate router not responding to probe packets does not necessarily mean business traffic is lost there. Only packet loss or high latency that consistently affects subsequent hops deserves more attention.

Why Domain Speed Tests Cannot Represent Full Page Speed

CdnChart currently displays domain HTTP access and its resolution, connection, download, and other results. It does not execute full JavaScript in a browser and cannot directly determine when a page finishes rendering.

A homepage HTML document may return quickly, but the page may still open slowly for the following reasons:

• 
  CSS or JavaScript blocks rendering;
  

• 
  Homepage images are too large;
  

• 
  Fonts load from overseas third-party domains;
  

• 
  API responses are slow;
  

• 
  Advertising, analytics, or customer service scripts time out;
  

• 
  JavaScript execution takes too long;
  

• 
  Page layout changes frequently;
  

• 
  User devices have low performance.
  

In this case, open the Network panel in Chrome DevTools and check the status, size, Timing, and Waterfall for all resources. Chrome's official documentation states that the Network panel can record page requests and display DNS, connection, time to first byte, and content download stages separately.

Multi-node domain speed testing answers 'which regions and carriers have access problems,' while browser tools answer 'which resource in the page is slowing down loading.' Combine both to move from network issues to specific resources.

How to Run Domain Speed Tests Before and After CDN Migration

If a domain is being switched from a direct origin connection to a CDN, or from one CDN to another, keep a test record.

Record before migration:

• 
  Test time;
  

• 
  Node scope;
  

• 
  Response IPs by carrier;
  

• 
  Status codes;
  

• 
  Resolution, connection, download, and total time;
  

• 
  Failed nodes;
  

• 
  Current DNS TTL;
  

• 
  Current CNAME or A records.
  

After migration is complete, retest with the same node scope and focus on:

• 
  Whether any nodes still resolve to the old IP;
  

• 
  Whether the new CDN covers core regions;
  

• 
  Whether China Telecom, China Unicom, and China Mobile have all switched;
  

• 
  Whether status codes and redirects have changed;
  

• 
  Whether failed nodes have increased;
  

• 
  Whether connection and total time have improved;
  

• 
  Whether DNS caches are still within the TTL window.
  

Do not declare migration successful based on a few nodes just minutes after DNS changes. Different recursive DNS servers may update caches at different times; wait for the original TTL window and continue monitoring the ratio of old to new IPs.

An Actionable Domain Speed Test Interpretation Table

This table helps narrow down the direction but cannot replace CDN logs, origin monitoring, and application performance data. External speed tests show user-side access results; to understand why the server is slow internally, you also need CPU, memory, disk, database, cache hit rate, and API logs.

FAQ

Does the CdnChart domain speed test require an HTTP or HTTPS address?

Enter the domain according to the example in the speed test page's input box.www.example.comBefore testing, confirm that you are entering the domain actually used publicly, do not substitute the origin IP, and do not mix different subdomains as the same test target.

If a domain speed test is normal once, does that prove the website has no problems?

No. A single result only represents the nodes and network status at that time. For intermittent slowness, evening peak anomalies, or regional failures, repeat tests at different times and keep records of response IPs and failed nodes.

Is a lower average time in a domain speed test always better?

Generally, lower is better, but comparisons must consider status codes, content size, and node scope. A small page returning 403 may be fast but does not mean the website is normal; times for different content cannot be compared directly.

Why do different regions get different response IPs in speed tests?

The website may use smart DNS, CDN, Anycast, or multi-CDN scheduling. Different IPs returned by different regions and carriers are usually normal; the key is whether those nodes are consistently accessible and whether they meet the network requirements of the target region.

Why is CdnChart total time still high when Ping latency is low?

Ping only measures ICMP round-trip time. Domain access also includes DNS, connection, TLS, server or CDN processing, content download, and redirects. Slowness at any subsequent stage will noticeably increase total time.

Can the CdnChart domain speed test measure TLS handshake time?

Current public results mainly show resolution, connection, download, total time, status code, response IP, and redirects; TLS handshake time is not listed separately. If you need to break down TLS, time to first byte, and other stages, you can usecurl -wor the browser Network panel as a supplement.

If a speed test node shows a failure, does that mean the website is down?

Not necessarily. A single node failure may come from the node's network, WAF blocking, access rate limiting, DNS errors, or a temporary timeout. Only when multiple nodes in the same region and on the same carrier fail continuously is it more likely a regional failure.

Can a domain speed test replace server monitoring?

No. Domain speed tests are suitable for observing regional differences and user access results from the outside; server monitoring tracks CPU, memory, disk, connection count, application errors, and database status. The two types of data need to be used together.