Which Metrics Should You Check in a Website Speed Test for Domestic Access?

The speed test dashboard is all green, yet users keep complaining in the backend that "the website is laggy." This usually happens because we're looking at too narrow a set of metrics. The network environment in mainland China is extremely complex—not only are there line differences among China Telecom, China Unicom, and China Mobile, but DNS scheduling and CDN node coverage also vary greatly from region to region. Staring only at the average response time of a single city easily masks high latency in specific areas or packet loss during evening peak hours. This article will walk you through the key metrics to focus on in domesticwebsite speed tests, analyze the differences across the three major carriers and various regions, and teach you how to quickly determine from concrete speed test data whether the network is slow or the server is slow—so you can accurately improve the access experience for users nationwide.

1. Why can't domestic website access speed tests rely on averages alone?

The biggest difference between testing domestic website access and testing from a single region is that users don't access the website through the same network. Beijing Telecom, Shanghai Unicom, and Guangdong Mobile—even when accessing the exact same domain—may go through entirely different carrier networks, backbone routes, DNS resolution results, and CDN nodes.

This is also why some site owners always find their own access fast, yet the backend keeps receiving feedback that "pages open slowly."

For example, a nationwide speed test might show:

If you only calculate the nationwide average, the resulting number may still fall within what looks like a normal range. But what truly deserves attention is that mobile networks are already showing noticeably slower access. When conducting domestic website access speed tests, rather than first asking "what's the average latency," it's better to look at the following aspects that offer more diagnostic value.

2. Five key aspects to focus on in domestic website access speed tests

1. Are there obvious speed differences across regions nationwide?

The first thing to look at in domestic speed tests isn't the fastest node, but whether the nationwide results are relatively balanced.

If access in Beijing, Shanghai, Hangzhou, and Nanjing is fairly normal, but Guangzhou, Chengdu, Xi'an, or other regions are noticeably higher, it indicates the website may have regional line or node issues.

This kind of situation commonly occurs with:

• The server is deployed too far from some users;

• Uneven CDN node coverage;

• Some regions are scheduled to farther nodes;

• Regional carrier line quality fluctuations;

• Origin-pull routes taking detours.

For example, if a website's server is deployed in East China without a CDN, users in East China may consistently see access in the tens of milliseconds, but users in Southwest, South China, or even Northeast China may see significantly higher latency.

In this case, the nationwide average latency doesn't truly reflect user experience. What's more worth noting is: whether any particular region is overall slower, and whether those slow nodes are concentrated in neighboring provinces. If the anomalies show clear geographic clustering, the troubleshooting direction is usually much clearer than simply looking at a single high latency number.

2. Is access balanced across Telecom, Unicom, and Mobile?

Another key point in domestic website speed tests is the difference between carriers. In the same city, access results can be completely different across carriers.

For example:

In this situation, if Telecom and Unicom are basically normal and only Mobile is noticeably higher across multiple regions, there's no need to start by checking server CPU, database, or website code.

Because if the server were truly slow overall, it typically wouldn't affect only one carrier.

A more reasonable troubleshooting direction would be: the line quality from Mobile networks to the server; cross-carrier interconnection; whether the CDN has assigned appropriate nodes to Mobile users; whether there are differences in DNS scheduling results; whether a particular backbone route is congested. Conversely, if Telecom, Unicom, and Mobile are all slow simultaneously, the problem is more likely to be in the server, origin, overall CDN configuration, or the website itself. So when conducting domestic access speed tests, whether the three carriers are balanced is often more valuable than a single nationwide average number.

3. Is it the network that's slow, or the server response?

After seeing that a website opens slowly, another commonly confused question is: is it the network line that's slow, or the server itself that's slow at processing requests? Both types of problems ultimately manifest as "the page takes a long time to open," but the troubleshooting directions are completely different. For example: a node's network round-trip latency is only 30ms, but the website actually takes 800ms or even 1 second to return content. In this case, continuing to agonize over line distance is usually pointless.

What should be checked instead: whether the web server is too slow at processing requests; execution time of dynamic programs like PHP, Java, Node.js; database queries; third-party APIs; CDN origin-pull; the page's dynamic generation process. Conversely, if the baseline network latency itself is already 150ms or 200ms, all subsequent HTTP requests will be built on that network foundation, and line and node distance should be checked first.

In practical analysis, you can simply understand it as: low network latency but slow page response—check the server and application first; high network latency itself—check lines, nodes, and carrier networks first. There's no need to fixate on any single metric; the key is to look at the network phase and the server processing phase together.

4. Are there a few abnormal nodes?

This is a point that's very easily overlooked in domestic website speed tests. Suppose a test has 50 nationwide nodes, of which:

• 42 nodes have latency between 30–60ms;

• 5 nodes exceed 100ms;

• 2 nodes occasionally time out;

• 1 node is completely inaccessible.

The final calculated average may still look good. But for real users, the access experience in the regions where those abnormal nodes are located has already become problematic. Especially for e-commerce, SaaS, content websites, or businesses with nationwide user coverage, you can't simply ignore a few abnormal regions just because "the vast majority of regions are normal."

In speed test results, pay special attention to several situations:

First, a single region suddenly being noticeably higher than surrounding regions.

For example, Hunan, Jiangxi, and Guangdong are all normal, but a certain carrier in Guangxi has particularly high latency.

This situation looks more like a localized line or node issue.

Second, the same carrier being high across multiple regions simultaneously.

This situation is more worth checking for carrier lines, cross-network interconnection, or CDN scheduling.

Third, some nodes timing out directly.

If it's just slow, the website can at least still be accessed; once continuous timeouts occur, you need to further confirm whether ICMP is being restricted or whether the HTTP request itself has also failed.

Therefore, when looking at domestic speed test results, don't judge good or bad solely by "average value from low to high."

Abnormal nodes themselves are very important information.

5. Is website access speed stable?

Website access speed isn't just about a single test being fast enough. If a morning test shows only 35ms, the afternoon shows 70ms, and the evening peak rises to 120ms, this kind of website may still have unstable real-world experience even if the average data isn't particularly bad.

This is especially true for the evening peak problem common to domestic websites, which a single test easily misses.

Common causes of significant website speed fluctuations include:

• Carrier peak-hour congestion;

• CDN node load changes;

• Node rescheduling;

• Network jitter or packet loss;

• Increased origin load;

• Origin-pull line fluctuations.

If users report "sometimes fast, sometimes slow," a single test usually can't explain the problem. It's best to run multiple tests at different times: morning, afternoon, and evening peak. If the same node produces similar results each time, the line is relatively stable; if test results frequently jump from tens of milliseconds to hundreds of milliseconds, you need to further observe whether there are fluctuations in network quality and server load.

3. Several speed test data points are best judged together

Although domestic website speed tests show a lot of data, there's no need to analyze every metric separately during actual troubleshooting. A more practical approach is to combine several data points based on different symptoms.

Network latency is normal, but website response is very slow

This situation usually indicates there's no obvious problem with the baseline network between the user and the server. The troubleshooting focus can shift to: server processing, database, dynamic programs, caching, or CDN origin-pull. For example, if network latency is only 30ms but the first byte takes forever to return, the line may not be the main bottleneck.

Both network latency and website response are slow

If network latency itself is already noticeably high, overall website response will usually slow down accordingly. In this case, check first: server deployment region, CDN nodes, cross-carrier lines, and whether users are being scheduled to farther locations.

Latency isn't high, but results fluctuate greatly

In this situation, pay attention to network stability.

For example, several consecutive tests show:

35ms, 42ms, 180ms, 38ms, 210ms.

Looking only at the lowest value, there's no problem, but the overall fluctuation is already very obvious. If accompanied by packet loss, it's even more likely to cause occasional page lag, request retries, or even loading failures.

Most regions nationwide are normal, only a few are slow

In this situation, don't rush to touch the server. First confirm whether the slow nodes are: in the same province, the same region, or the same carrier. The more concentrated the abnormal nodes, the easier it usually is to pinpoint the problem.

4. What counts as normal for domestic website access speed?

Website type, server location, page content, and whether a CDN is used all vary, so there's no fixed number that all domestic websites must meet for access speed. However, for daily troubleshooting, some ranges can be used as initial references:

These numbers are better used to spot obvious anomalies than as hard-and-fast standards. For example, a server deployed in Hong Kong or overseas will naturally have RTT values that can't be identical to those of a server on the mainland; likewise, TTFB for dynamic pages and static pages can't be compared directly.

When judging site speed, what matters more is still this: whether there are obvious anomalies between nodes of the same type, and whether the current results have changed compared with the site's usual baseline.

5. How do you run a website speed test for mainland China?

If your site's users are mainly in mainland China, the simplest, most direct, and most effective method is to test with Chahu's nationwide multi-node speed test tool, rather than just opening the site once on your own computer.

Take Chahu as an example: after entering the website address, you can directly view test results from different regions across the country as well as from the three major networks—China Telecom, China Unicom, and China Mobile—without having to manually select carrier nodes one by one.

When testing, you can review the results in the following order.

Step 1: First check whether any regions show obvious anomalies in the nationwide results

Don't rush to find the fastest node. First quickly scan the nationwide results to see whether certain provinces are noticeably slower than others, or whether timeouts or access failures appear. If most regions are normal and only a few nodes are abnormal, you can then narrow the scope to specific regions.

Step 2: Then compare China Telecom, China Unicom, and China Mobile

Next, observe whether the anomalies show a clear carrier pattern. For example: China Telecom and China Unicom are normal, while multiple China Mobile nodes remain consistently high. This kind of result is usually more useful for troubleshooting than "national average speed 50ms," because it has already narrowed the problem from the entire website down to a certain type of network.

Step 3: Determine whether the slowness is in the network stage or the website response stage

If you find abnormal speed in a certain region, you can continue to combine Ping, DNS, connection time, and website response results to determine which segment the problem occurs in.

Chahu itself can also continue to use Ping, DNS detection, and other functions for cross-verification. This helps avoid seeing a "website is slow" result and immediately concluding that server performance is insufficient.

Step 4: Test again at a different time

If the first test shows obvious anomalies, it's best not to draw a conclusion immediately. You can test again after some time, especially during the evening peak. If the same batch of nodes remains abnormal, the problem is usually more worth investigating further; if the second test fully recovers, it may just have been a short-term line fluctuation.

6. Where should you check first for different test symptoms?

If you don't want to analyze every parameter item by item, you can determine the troubleshooting direction directly based on the speed test symptoms.

This table is better used as a preliminary localization tool. When truly complex problems arise, you still need to confirm further by combining specific nodes, MTR, server monitoring, and access logs.

Conclusion

Understanding speed test metrics is essentially about performing a full-link diagnosis for your website. Put aside self-comforting data like "national average 40ms," and learn to look at the core metrics together—RTT network latency, TTFB response time, and the distribution across the three major carriers. Then you can tell at a glance whether China Mobile's route is taking a detour or whether the origin database is dragging things down. First use nationwide multi-node testing to pinpoint abnormal metrics, then adjust nodes and optimize the server side accordingly—that is the most time-saving and effort-saving optimization path.

Related Q&A

Q1: What do RTT, TCP connection time, and TTFB each represent during a speed test?

Simply put: RTT is the pure round-trip time for data packets traveling over the network; TCP connection time includes the time for network handshaking and connection establishment; and TTFB (Time to First Byte) is the time from initiating the request to receiving the first batch of data returned by the server. It directly reflects how fast the server processes business logic and database queries.

Q2: Why does speed test latency increase noticeably after a website enables HTTPS?

In addition to the traditional TCP three-way handshake, HTTPS also requires a TLS certificate handshake and key negotiation, which adds 1–2 additional network round trips (RTT). If TLS Record Size optimization, HTTP/2, or Session Resumption is not configured in mainland China, latency can feel noticeably higher on nodes with poorer network conditions.

Q3: Ping test latency is very low, but opening the page in a browser is still slow. How do you troubleshoot?

Ping uses the ICMP protocol, so it can only indicate whether the network layer is reachable and fast. Actually opening a web page uses the HTTP/HTTPS protocol and involves front-end resource loading. If Ping data looks good but the page is slow, you can open the browser developer tools (F12) and check the Network panel to see whether images are too large, third-party JS scripts are blocking, static resources are not using Gzip/Brotli compression, or too many DOM nodes are causing rendering delays.

Q4: Speed test data varies greatly at different times (for example, especially slow at night). How should this be solved?

This is a typical case of "evening peak network congestion." If the origin runs in a single-line data center, consider introducing intelligent DNS to achieve traffic splitting across the three major carriers; if CDN nodes are overloaded at night, you need to replace or add high-quality CDN nodes that support dynamic scheduling and strong defense capabilities, or even configure premium origin pull lines separately for China Mobile or China Unicom.

Q5: Is there a big difference in speed between IPv6 and IPv4 when testing in mainland China?

IPv6 deployment in mainland China is now very widespread, but in some regions or local carrier networks, IPv6 route optimization and node scheduling policies may not be fully consistent with IPv4. Sometimes IPv4 latency is low while IPv6 takes a detour. When troubleshooting, it is recommended to test dual-stack (IPv4/IPv6) separately to ensure that the resolution and access quality of IPv6 nodes are not dragging down overall speed.