Which Website Speed Test Tool Is Right for You? Domestic Three-Carrier Testing vs. Web Performance Scoring

When a website loads slowly, many people first look for a website speed test tool, enter the domain, and then judge whether the site is fast based on the seconds or performance score shown at the end.

Once you start testing, more questions appear: a mainland China speed test platform shows slow China Mobile routes, while PageSpeed Insights gives a high performance score; PageSpeed mobile scores only 50, yet the site feels fast when you open it on a China Telecom broadband connection; one tool says the page loads in 3 seconds, while another says Largest Contentful Paint takes 5 seconds.

These results are not necessarily contradictory, because “website speed” is not a single metric. When users open a page, they go through at least DNS resolution, connection establishment, TLS handshake, server response, resource download, browser rendering, and page interaction. Different tools observe different parts of this process.

So when asking which website speed test tool is best, you should not rely only on brand reputation or how polished the report looks. A more practical approach is to answer one question first: do you want to know whether users in mainland China can connect to the site quickly and reliably, or whether the page can finish rendering quickly once it reaches the browser?

To check access differences across regions in mainland China and among China Telecom, China Unicom, and China Mobile, prioritize multi-node testing across the three major carriers. To analyze above-the-fold content, JavaScript execution, and page layout, use web performance tools such as PageSpeed Insights and Lighthouse. Most production websites need both types of tools working together, not one or the other.

Which website speed test tool is best? Start with the type of problem you need to solve

Common website speed test tools fall roughly into four categories. They may all be called “website speed tests,” but they answer different questions.

If a website mainly serves users in mainland China, the first troubleshooting step should usually be multi-node testing across the three major carriers. You first need to confirm whether users can access the site, which node they reach, and whether slowness is concentrated in specific regions or carriers.

If basic access shows no obvious issues, then use web performance scoring to identify image, CSS, JavaScript, font, and page layout problems. This sequence makes it easier to find the real bottleneck than staring at the PageSpeed score from the start.

What exactly does multi-node testing across China's three major carriers measure?

Multi-node testing across China's three major carriers is not simply requesting the website from three servers. An effective test needs to cover multiple provinces, cities, and network egress points, distinguish China Telecom, China Unicom, and China Mobile, and, where possible, include residential networks and different types of test environments.

This is because “the website is fast in mainland China” is itself too broad. Normal access from China Telecom in Beijing does not mean China Mobile in Guangxi is also normal; resolution to an East China node from China Unicom in Shanghai does not mean users in the northwest will not be routed to a distant IP; fast broadband access in the webmaster's office does not represent the real experience of users nationwide.

Usingmulti-node website speed testing across China's three major carriersCdnChart launches tests against the target domain from different regions and carriers, and displays results such as test nodes, response IPs, IP locations, HTTP status codes, resolution time, connection time, download time, total time, redirects, and failed nodes.

These metrics need to be read together; do not focus only on the final total time column.

Status codes determine whether users actually access the site successfully

If most nodes return 200 and a few China Mobile nodes return 403, the problem is not simply “China Mobile is slow”; it may be blocking caused by WAF, access control, geo policies, or node rules.

If 502, 503, or 504 appears, determine whether the failure occurs at the CDN edge node, the origin fetch path, or the origin server. Even if successful nodes have very low average time, that does not mean overall website availability is normal.

Response IPs reveal CDN routing results

After CDN is enabled, it is usually normal for the same domain to resolve to multiple IPs in different regions. What matters is whether slow nodes are concentrated on certain response IPs, whether those IPs are too far from users, or whether one carrier is frequently routed to nodes on another network.

For example, if China Telecom and China Unicom access are normal while connection time remains high on multiple China Mobile nodes, check China Mobile route coverage, cross-carrier paths, and CDN routing first, rather than blaming the page code.

Resolution, connection, and download times point to different problems

• High resolution time:Focus on authoritative DNS, recursive resolution, CNAME chains, and DNS routing.

• High connection time:Focus on node distance, network routing, cross-carrier access, and TCP connection setup.

• High download time:May be related to file size, node bandwidth, cache status, or transmission quality.

• High redirect time:Check whether HTTP-to-HTTPS, apex-domain, geo, and login redirects are stacked.

• Some nodes fail:Check WAF policies, node health, DNS anomalies, and origin failures.

The advantage of multi-node testing across China's three major carriers is that it turns “some users say the website is slow” into more specific questions: which region is slow, which carrier is slow, which IP was resolved, whether the delay is in resolution or connection, and whether status code anomalies accompany it.

However, these active probe results mainly describe the network request process; they are not the same as the full browser rendering experience. They can show whether HTML or the tested resource is fetched quickly, but they cannot by themselves prove when users see above-the-fold content.

What does web performance scoring measure?

PageSpeed Insights and Lighthouse are closer to the browser's perspective. They load the page, execute resources, and observe when page content appears, whether the main thread is blocked for long periods, and whether layout shifts.

According tothe official PageSpeed Insights documentationreports usually include two types of data: lab data generated by Lighthouse in a simulated environment, and field data from the Chrome UX Report.

These two types of data should not be conflated.

Lighthouse lab data is suited to locating front-end problems

Lab tests load the page under relatively fixed device and network conditions. Common results include:

• FCP:The time when the page first displays text, images, or other content;

• LCP:The time when the largest content element in the viewport finishes rendering;

• Speed Index:How quickly visible content fills in on the page;

• TBT:The extent to which long tasks block the main thread during page load;

• CLS:The extent of unexpected layout shifts during page load.

The page performance score is also not load time in seconds. According tothe Lighthouse performance scoring rulesthe final score is calculated from multiple metrics using scoring curves and weights, and the scoring model and weights may change between versions.

Therefore, a score of 85 cannot be interpreted as “the page takes 0.85 seconds to open,” and a score of 90 does not prove that users nationwide can access it quickly.

CrUX field data reflects real experience over a period of time

Data from the Chrome UX Report in PageSpeed reflects the historical experience of eligible real Chrome users on different devices and networks. It usually uses rolling data from the past 28 days and evaluates metric performance based on the 75th percentile.

Current Core Web Vitals mainly focus on LCP, INP, and CLS. You can usethe Web Vitals metric definitionsto understand the scope of these metrics, but note that CrUX is not a complete count of all website visitors and does not provide carrier-level breakdowns such as China Telecom, China Unicom, and China Mobile.

If a page has low traffic, PageSpeed may not have enough URL-level field data and may show only origin-level data or no field data at all. This does not mean the website is inaccessible; it only means the public sample is insufficient.

Multi-carrier speed testing or web performance scoring: which should you choose?

The choice is not complicated: first decide the testing layer based on the business question.

If the website's main users are in mainland China, first use CdnChart to confirm access quality across the three major carriers, then use PageSpeed to check front-end rendering. If the main users are overseas, first select test nodes close to the target countries, then analyze web performance.

Test nodes should not be selected based on server location; instead,arrange website speed tests based on real user locationsA server in Hong Kong does not mean you only need to test Hong Kong; if users are concentrated in Guangdong, Zhejiang, and Jiangsu, prioritize those regions and their major carriers.

Why do the two types of tools often reach opposite conclusions?

Case 1: CdnChart is fast, but the PageSpeed score is low

This usually means basic network requests have no obvious problems, but browser rendering is slow. Common causes include oversized above-the-fold images, long JavaScript execution, render-blocking CSS, too many third-party scripts, slow font loading, or layout shifts.

CDN can shorten resource transmission time, but it cannot automatically reduce JavaScript computation or fix incorrect image dimensions and page layout for developers.

Case 2: PageSpeed score is high, but some regions in mainland China are still slow

A single PageSpeed lab test cannot represent all provinces and carriers in mainland China. Fast access to a CDN node in the test environment does not mean China Mobile or remote areas will hit the same node.

If slow nodes are concentrated on one carrier, check connection time and response IPs first; if node status codes differ, check WAF, access control, and node configuration; if resolution time varies widely, check DNS and CNAME chains.

Case 3: Lighthouse looks good, but CrUX is still poor

Lighthouse reflects one current simulated test, while CrUX reflects the distribution of real users over a period of time. When a website has just been optimized, old data may still remain in the rolling statistics window.

Another possibility is that the lab test page is relatively stable, but real users have lower-performance devices, worse networks, or encounter login states, ads, cookie prompts, personalized content, and actual interactions.

Case 4: Repeated tests with the same tool are inconsistent

A single result is affected by cache warmness, CDN node load, origin load, network routing, dynamic content, and third-party services. Website speed should be viewed as a distribution, not a fixed number.

In this case, continue comparingmulti-node network speed test and PageSpeed performance dataand record network requests, browser rendering, and historical user experience separately instead of keeping only one best score.

How can you build a website speed testing process that actually works?

When launching a website, migrating CDN, or optimizing performance, test in the following order.

Step 1: Define the test pages

Do not test only the homepage. At minimum, select:

• Homepage;

• High-traffic content pages;

• Pages with many images or static resources;

• Pages with many dynamic API calls;

• Key business pages such as login, search, or purchase.

Different pages may use different templates, cache rules, and APIs. Testing only the homepage can easily miss slow pages that truly affect users.

Step 2: Define user regions and carriers

For mainland China operations, at least split by China Telecom, China Unicom, and China Mobile, and focus on the provinces where your main users are located. Do not ignore regions that account for a large share of business traffic just because the national average looks normal.

If the business covers both mainland China and overseas markets, set up separate test groups; do not directly average results from Shanghai, Tokyo, Singapore, Frankfurt, and Los Angeles into a single number.

Step 3: Check availability and network paths first

Run multi-node speed tests in CdnChart and record status codes, failed nodes, response IPs, resolution time, connection time, download time, and total time. Focus on whether slow nodes are concentrated in a particular region, carrier, or response IP.

At this stage, the goal is not a good-looking average number, but finding obvious weak spots in the user base.

Step 4: Then check page rendering and interaction

Use PageSpeed Insights to test mobile and desktop separately, and review LCP elements, TBT, CLS, blocking resources, image, and JavaScript issues. Record field data and lab data separately; do not mix them into one test conclusion.

Step 5: Retest under the same conditions after changes

Before and after optimization, use the same URL, region, carrier, and device type. Repeat tests at different times and retain slow and failed nodes, rather than screenshotting only the best run.

If you need to compare the functional boundaries of more tools, start withthe applicable scope of different website speed test platformsand choose supporting tools based on node coverage, metric definitions, browser analysis capabilities, and how results are saved.

To judge whether a website is really faster, look at at least three sets of results

A speed test conclusion usable for launch acceptance should not be only “PageSpeed improved from 70 to 90,” nor only “average time dropped by 0.3 seconds.” A more reliable judgment needs to cover three sets of results at the same time.

The first set is access availability:Whether timeouts, 403, or 5xx occur in target regions, and whether critical carriers have concentrated failures.

The second set is network paths:Whether DNS, connection, download, and total time improve, whether slow nodes decrease, and whether response IP routing matches expectations.

The third set is web experience:Whether LCP, INP, and CLS improve, and whether low-performance mobile devices are still affected by scripts, images, and main-thread blocking.

CdnChart's value is mainly in the first and second sets: expanding subjective experience on a single computer into comparable results across regions, carriers, and response IPs. PageSpeed, Lighthouse, and real user monitoring complement the third set, showing site owners browser rendering and real interaction experience.

Only by combining the two types of tools can you distinguish two completely different problems: “the network did not deliver content to users in time” and “the content was delivered, but the browser did not display it in time.”

Frequently asked questions

Which website speed test tool is best? Can you recommend just one?

If a website mainly serves users in mainland China and the current goal is to troubleshoot regional, carrier, or CDN issues, prioritize CdnChart for multi-node testing across the three major carriers. If the goal is to optimize above-the-fold content, JavaScript, and Core Web Vitals, prioritize PageSpeed Insights. For formal launch acceptance, use both together rather than relying on a single tool.

Does a high PageSpeed score mean a website is fast in mainland China?

No. The PageSpeed score mainly reflects web performance in a specific environment. It cannot prove that China Telecom, China Unicom, and China Mobile users nationwide can connect quickly, nor can it rule out failed nodes, error status codes, or abnormal CDN routing in some regions.

Multi-carrier speed tests are fast in mainland China, so why do users still say the page lags?

Normal three-carrier speed test results only show that network requests and resource transmission have no obvious anomalies. User-perceived lag can also come from long JavaScript tasks, API waits, above-the-fold images, fonts, third-party scripts, or interaction response issues. Continue checking LCP, INP, and browser performance records.

Should I enter a domain or a full URL for speed testing?

When troubleshooting DNS and CDN routing, you can start with the domain homepage, but when validating real business experience, test the full URL, including protocol, subdomain, path, and query parameters. Homepages, content pages, login pages, and APIs may use different cache and origin fetch rules.

Why do repeated speed tests of the same website produce different results?

Network routing, node load, origin load, cache status, dynamic content, and third-party resources all change. Repeat tests under the same conditions and compare result distribution, slow nodes, and failed nodes; do not treat one best or worst result as a long-term conclusion.

Do I need to select all nodes for multi-carrier testing in mainland China?

For initial troubleshooting, you can expand the node range to discover unknown regional and carrier issues. Once in the retest phase, focus on retaining the provinces and carriers where business users are concentrated, while selecting a small number of other regions as controls.

After switching CDN, is it enough to look only at average time?

No. Averages can hide a few severely slow nodes. You also need to compare the slowest results, failed nodes, performance by carrier, response IP changes, status codes, and redirects. For business-critical regions, looking at them separately is more meaningful than a national average.

Can CdnChart replace real user monitoring?

No. CdnChart is suited to active probing, regional comparison, and problem discovery, while real user monitoring is suited to long-term observation of user devices, networks, and interaction experience. Before final vendor selection or CDN migration, enterprises should also run real business URL tests, trials, or POCs, and make comprehensive judgments based on price, contracts, security capabilities, and technical support.