How to Test Domain Speed: Methods for Checking Domain Access Speed and Network Latency

After you enter a domain name, several steps still stand between that input and a page actually opening: DNS resolution, network connection, server response, and more. If any one of these steps goes wrong, you may see high access latency, certain regions failing to open the site, or the same domain performing very differently across ISPs. Domain speed testing cannot rely on a single Ping value. In practice, you also need to consider DNS resolution results, network latency, packet loss rate, nodes in different regions, and the performance of China Telecom, China Unicom, and China Mobile together. This article starts from the actual testing process and explains what domain speed testing should measure, how to interpret the results, and where to begin troubleshooting when domain access speed is abnormal.

1. What Is Domain Speed Testing?

Simply put, domain speed testing checks whether the link from DNS resolution to network access is working properly for a domain.

For example, testing:

www.example.com

It is not just about whether the URL eventually opens. You also need to watch for resolution errors, excessive latency, or packet loss during access.

Common domain speed testing items mainly include:

• Whether the domain resolves normally;

• Which IP it currently resolves to;

• What the Ping latency is;

• Whether packet loss exists;

• Whether network latency is consistent across regions;

• Whether there are obvious differences among China Telecom, China Unicom, and China Mobile;

• Whether HTTP or HTTPS responds normally.

This data helps determine whether the problem lies in domain resolution, network routing, or the server itself.

Here we also need to distinguish "domain speed testing" from "website speed testing."

Domain speed testing focuses more on DNS, network connectivity, Ping latency, and line quality. If you need to analyze images, JavaScript, CSS, first-screen rendering, or page resource loading, a website speed testing tool is more suitable.

2. Which Metrics Matter Most in Domain Speed Testing?

Domain speed test results may contain many data points, but when troubleshooting, you do not need to study every parameter. Usually, looking at the following core metrics first is enough to diagnose most network problems.

1. Whether DNS Resolution Is Normal

When a user accesses a domain, the browser's first step is to ask DNS for the IP: example.com → 1.2.3.4

If resolution gets stuck at this step, no amount of network speed later will help. During testing, check directly:

• Does it return an IP smoothly?

• Can all nationwide nodes resolve it, or do some regions time out?

• Is the resolved IP correct? (Has it been poisoned or landed on the wrong node?)

If some locations consistently fail to get an IP or time out during resolution, check the DNS records first or see whether the DNS provider has issues. Do not rush to touch the server.

2. Ping Latency

Ping is the most direct metric for measuring network-layer response. For example, test results might show:

• Beijing Unicom: 32 ms

• Shanghai Telecom: 28 ms

• Guangzhou Mobile: 45 ms

The millisecond value here is the round-trip time for data to travel between your test node and the server. The smaller the number, the smoother the physical and network path.

But do not equate Ping with page opening speed. Ping may be only 30 ms, but if the server runs a slow database query that takes 1 second, the page will still hang. So Ping only proves "the path is open and fast"; it does not prove "the server processes quickly."

3. Packet Loss Rate

Besides latency, packet loss is also a very important data point in domain speed testing.

For example, compare these two results:

Latency: 35 ms\nPacket loss: 0%

and:

Latency: 25 ms\nPacket loss: 15%

Although the second group has a lower Ping value, its actual network quality may be worse.

Continuous packet loss causes data retransmission, and in severe cases may lead to: pages occasionally failing to open; request stuttering; TCP retransmission; API timeouts; image loading failures; unstable long connections. So when judging domain network quality, do not stare only at average latency. If a region or ISP consistently shows obvious packet loss, it is usually worth further checking line quality.

4. Speed Test Results in Different Regions

Pinging from your own computer has no reference value; it only represents your current broadband connection. For a website serving nationwide users, you must look at multi-location distribution:

• Normal case: Beijing 35 ms / Shanghai 28 ms / Guangzhou 42 ms / Chengdu 78 ms / Wuhan 39 ms (overall fluctuating within a reasonable range).

• Abnormal case: Beijing 35 ms / Shanghai 31 ms / Guangzhou 40 ms / Chengdu 186 ms / Wuhan 38 ms.

When only Chengdu is high like this, it is most likely not that the server itself cannot handle the load, but that the local ISP's outbound routing takes a detour or the line is congested.

5. Differences Among China Telecom, China Unicom, and China Mobile

For websites in China, you must look at China Telecom, China Unicom, and China Mobile separately. For example:

• China Telecom: 30–40 ms

• China Unicom: 35–50 ms

• China Mobile: 110–150 ms

When you see data like this, do not vaguely say "the website got slower." The accurate conclusion is: "China Mobile routing is lagging, while China Telecom and China Unicom are normal." This is mostly caused by high cross-network interconnection latency in single-line data centers, lack of BGP routing, or CDN failing to assign China Mobile users to suitable nodes. Breaking the analysis down by ISP is far more useful than looking at a nationwide average.

3. How to Test Domain Speed

If you just want to check temporarily whether a domain has obvious network abnormalities, there is no need to prepare multiple servers in different regions yourself.

Using an online tool for direct multi-node testing is more convenient.

1. Use Chahu for Domain Speed Testing

Open the Chahu Ping test page directly and enter the domain or URL you need to test.

For example:

www.example.com

After submitting the test, you can directly view results returned from different regions and ISPs across the country.

Chahu tests the target from nationwide three-network environments, so you do not need to manually select a particular China Telecom, China Unicom, or China Mobile node first.

After the test is complete, it is recommended to focus first on the following items:

• The IP resolved from the domain;

• Ping latency at each node;

• Whether packet loss exists;

• Latency differences between regions;

• Performance across China Telecom, China Unicom, and China Mobile.

For example, test results might be:

Beijing Unicom    32 ms\nShanghai Telecom    27 ms\nGuangzhou Mobile    45 ms\nChengdu Telecom    61 ms\nWuhan Unicom    39 ms

If most nodes fall within a similar range and there is no obvious packet loss, it usually means the domain's current network connectivity is not a major problem.

2. First Check for Large-Scale Abnormalities

After getting nationwide node results, do not rush to analyze a single number. Look at the overall distribution first.

For example, most nodes are:

30–60 ms

and only one node occasionally shows:

180 ms

This situation looks more like local line fluctuation.

But if a previously normal domain suddenly shows:

Beijing: 210 ms\nShanghai: 185 ms\nGuangzhou: 230 ms\nChengdu: 198 ms\nWuhan: 205 ms

and multiple ISPs rise at the same time, you should continue checking the server outbound connection, network routing, CDN nodes, or whether there is large-scale network congestion at the moment.

In other words, a single-node anomaly and a nationwide large-scale anomaly require completely different troubleshooting directions.

3. Then Check for Obvious ISP Differences

After confirming there is no large-scale abnormality overall, observe China Telecom, China Unicom, and China Mobile separately.

For example:

China Telecom average: 35 ms\nChina Unicom average: 42 ms\nChina Mobile average: 128 ms

This result is already quite clear.

The server is not slow for all users; rather, China Mobile users have relatively poor access quality.

For further troubleshooting, you should focus on China Mobile routing, cross-network paths, or node scheduling, rather than directly upgrading server CPU and memory.

This is also where multi-node domain speed testing is more valuable than single-machine Ping.

4. How to Interpret Domain Speed Test Results

Different speed test results point to different fault directions.

In actual troubleshooting, you can judge according to the following common situations.

1. Latency Is Relatively Low Nationwide

If latency in most regions is within a relatively low range, for example:

20–50 ms

and there is no obvious packet loss, it usually means:

• DNS resolution is basically normal;

• Network connectivity is normal;

• There is no obvious abnormality at the server outbound connection;

• Nationwide access routing is generally stable.

If users still report that pages open very slowly, the problem is likely no longer at the network layer.

At this point, you should continue checking server response, backend programs, databases, and page resource loading.

2. Only a Few Regions Have Very High Latency

For example:

Beijing: 32 ms\nShanghai: 28 ms\nGuangzhou: 35 ms\nChengdu: 190 ms

This kind of result looks more like a local line anomaly.

Common causes include:

• Local ISP network fluctuation;

• Routing detour;

• Cross-network access;

• Abnormal nodes in specific regions;

• Unreasonable CDN scheduling.

If the vast majority of regions are normal, there is no need to immediately conclude that the server itself lacks performance.

3. One ISP Is Generally Slow

If China Telecom and China Unicom latency is normal, but many China Mobile nodes are clearly high, then you need to focus on line quality between ISPs.

For example, if the server is deployed in a single-line China Telecom data center, China Mobile users may need to go through cross-network interconnection, so network latency will naturally be higher than for China Telecom users.

If the website serves nationwide users, you can further check:

• Whether multi-line BGP is used;

• Whether CDN scheduling is correct;

• Whether corresponding nodes exist for different ISPs;

• Whether cross-network access or detours exist.

4. Latency Is Normal but Packet Loss Is Severe

This is a type of problem that is relatively easy to overlook.

Some test results show Ping at only 30–40 ms, but at the same time show 10%, 20%, or even higher packet loss.

Such a network cannot be considered stable.

Packet loss causes TCP retransmission, and in actual access it may appear as:

• Pages occasionally freezing;

• Intermittent API timeouts;

• Download speeds fluctuating;

• Images occasionally failing to load;

• Unstable WebSocket connections.

So in domain speed testing, latency and packet loss are best examined together.

5. Ping Is Normal but Website Access Is Still Slow

This situation is also very common.

For example, nationwide Ping is basically 30–50 ms with no packet loss, but the page still takes several seconds to open.

At this point, you should shift troubleshooting from the network layer to the application layer.

Common causes include:

• Slow web server response;

• Long execution time of backend programs such as PHP, Java, or Node.js;

• Slow database queries;

• Slow API responses;

• Oversized page images;

• Many JavaScript and CSS resources;

• Third-party scripts blocking loading.

In other words: Normal Ping only means there is no obvious problem in the network round trip from the test node to the server. It does not prove that the entire page loading process is normal.

At this point, it is more appropriate to continue with website opening speed testing.

5. What Domain Latency in ms Is Considered Normal?

What Ping in ms is considered normal? There is no fixed answer that applies to all websites, because latency depends on server location, ISP, routing, and physical distance.

If used only as a daily troubleshooting reference, you can roughly view it as follows:

This range is only a reference and cannot be used mechanically. For example, when users in mainland China access domestic servers, 30–60 ms is very common; if accessing a US server, above 100 ms does not necessarily mean the network is faulty.

So rather than simply asking "how many milliseconds is normal," it is more worthwhile to watch for: whether results in the same region suddenly rise; whether there is an obvious gap between ISPs; whether high latency persists; and whether packet loss occurs at the same time. These changes are often more useful for judgment than an absolute number.

6. Why Do Speed Test Results for the Same Domain Differ by Region?

The same domain may test at only 30 ms in Beijing, 50 ms in Guangzhou, and over 100 ms overseas. This is not surprising.

Network access itself is affected by many factors.

1. Different Distances Between Users and Servers

The most direct reason is physical distance.

If the server is deployed in Beijing, the access path for Beijing users is usually shorter, while Guangzhou users need to traverse a longer backbone network.

Cross-border access involves even longer distances, and latency usually increases further.

So a certain Ping difference across regions is itself a normal phenomenon.

2. Different ISPs

China Telecom, China Unicom, and China Mobile have different backbone networks.

Even if users and the server are in the same city, different ISPs may take different network paths when accessing the same target.

Especially in cross-network access, latency tends to be more obvious.

3. Different Routing Paths

Internet transmission does not simply follow straight-line distances on a map.

How packets actually travel depends on ISP routing policies, network exits, and interconnection relationships.

Some routes can reach the target data center directly, while others may pass through more intermediate nodes.

Once an obvious detour occurs, Ping may suddenly rise even if the geographic distance is not far.

4. Impact of CDN or Smart DNS

If the domain uses CDN or smart DNS, users in different regions may be assigned to different nodes.

For example:

Beijing users → Beijing node\nShanghai users → Shanghai node\nGuangzhou users → Guangzhou node

The same domain resolving to different IPs in different regions is not necessarily abnormal. What really matters is whether users are scheduled to reasonable nodes and whether final access latency is stable.

7. What Is the Difference Between Domain Speed Testing and Website Speed Testing?

"Domain speed testing" and "website speed testing" are often mentioned together, but their focus is not exactly the same.

Simply put, domain speed testing mainly answers "is this access link open and fast," while website speed testing further answers "why does the webpage open fast or slow." If a domain itself has high Ping and obvious packet loss, network issues should be handled first. Only when the network layer is completely normal is it necessary to continue analyzing page loading performance.

Summary

The real value of domain speed testing is not obtaining a Ping number of a few dozen milliseconds, but gradually narrowing down where the problem lies through DNS, latency, packet loss, regional nodes, and ISP results. If most nodes nationwide show normal latency and no obvious packet loss, the network link is usually not the primary issue. If only a certain region or ISP consistently shows high latency, you should continue checking along the corresponding route rather than directly concluding that server performance is insufficient.

In actual troubleshooting, first use Chahu to check the domain's Ping and network performance across nationwide three-network environments, then continue judging with DNS and HTTP responses. Figure out first whether resolution is slow, the network is slow, or the server response is slow; only then will later optimization be more targeted.

Related Q&A

1. When dig and nslookup return different results for the same domain, which one should I trust?
Don't panic first; this is very common. nslookup uses the DNS configured on your local machine by default, which may be your ISP DNS or corporate internal DNS, and returns whatever is in its cache. dig can specify a server, such as dig @8.8.8.8 example.com, showing the result from Google DNS. I usually run dig +trace example.com again to query layer by layer from the root domain and see what the authoritative DNS actually returns. If the authoritative result is normal but the local one differs, it is most likely cache or ISP DNS causing trouble. Compare several public DNS servers, such as 223.5.5.5 and 119.29.29.29, and you will have a clearer picture.

2. If a domain uses a CDN, how do I know which node users are scheduled to?
Use nodes in different regions to dig the domain and look at the returned CNAME and A records. For example, if the IP returned in Beijing differs from Guangzhou, smart DNS is at work. Then look at HTTP response headers; curl -I can show fields such as X-Cache, Via, and Server, which can hint at which CDN node was hit. If the returned IPs are all the same, it may not be going through the CDN, or the CDN configuration may have issues. Do not look at just one location; compare several provincial nodes.

3. How is IPv6 domain speed testing different from IPv4?
First confirm whether the domain has an AAAA record: dig AAAA example.com. During testing, force IPv6 with curl -6 or ping6. Many online speed testing tools only test IPv4 by default, so IPv6 issues are easily missed. If IPv6 latency is especially high, routing may not be optimized or may be going through a tunnel. Use mtr -6 to inspect the path; sometimes IPv6 detours are much worse than IPv4. Mobile networks now have high IPv6 penetration, so do not ignore this area.

4. In a three-network speed test, China Mobile is especially slow while China Telecom and China Unicom are normal. What should I check next?
First check whether the IP resolved by China Mobile nodes differs from that of China Telecom and China Unicom. If it is the same, it is most likely a cross-network interconnection issue. Use a China Mobile node to run mtr to the target IP and see at which hop latency spikes. If it is a CDN, check whether China Mobile is scheduled to a nearby node; if not, consider switching to multi-line BGP or adding China Mobile nodes. Do not rush to upgrade server CPU; this has little to do with server performance.

5. How can I tell whether slow domain speed is a local network problem or a nationwide problem?

Use the Chahu multi-node speed testing tool directly to view the latency distribution on the nationwide map. If most regions nationwide are green (30–50 ms) and only Chengdu or one city shows red (200 ms+), it is just local ISP routing or node fluctuation. If all nodes nationwide and all three-network ISPs turn red at the same time, it is a nationwide anomaly caused by saturated server outbound bandwidth, data center failure, or an attack.