Inconsistent Website Speed Test Results? How to Cross-Check CDNChart Against PageSpeed Insights

Put the same page through CDNChart and PageSpeed Insights, and the results may appear contradictory:

• CDNChart shows total time exceeding 3 seconds in some regions, while PageSpeed gives a performance score of 90;

• CDNChart shows fast access across regions, while PageSpeed gives a mobile score of only 50;

• PageSpeed lab data looks good, while real-user data still shows “Needs improvement”;

• The site loads quickly from China Telecom nodes, yet PageSpeed results keep fluctuating.

These results do not necessarily mean either tool measured incorrectly. More often, the two tools are not measuring the same thing.

CDNChart mainly answers whether network requests for this URL go smoothly when users access it from different regions and carriers, which IP they are routed to, and how long each phase takes; PageSpeed Insights focuses more on how soon the main content appears after the browser opens the page, whether the page shifts, whether the main thread is blocked, and what real Chrome users experience.

CDNChart tends to check regions, carriers, DNS, CDN nodes, and the HTTP request path; PageSpeed tends to check browser rendering, front-end resources, and user experience metrics. The two should complement each other, not be compared directly as one total time versus one performance score.

CDNChart and PageSpeed do not measure the same layer

When website speed test results differ, the first step is not to see which number is lower, but to confirm what the number represents.

For example, “total time” in CDNChart cannot be compared directly with LCP in PageSpeed.

Total time reflects the network and transfer process involved when a test node requests the tested URL; LCP focuses on the time when the largest content element in the browser viewport finishes rendering. The latter is also affected by HTML parsing, CSS, JavaScript execution, fonts, image priority, and device performance.

Likewise, a PageSpeed score of “85” cannot be converted into “the site needs 1.5 seconds to open.” According tothe Lighthouse performance scoring documentation, the performance score is a composite result calculated from multiple metrics through scoring curves and weights; it is not a direct expression of the time taken by any single request.

PageSpeed reports actually contain two types of data

Many people treat every number on the PageSpeed page as the result of one speed test; this is another source of misjudgment.

PageSpeed Insights usually contains two types of data with completely different natures.

Real-user data: answers what users experienced over a period of time

The top of the report may show data from the Chrome User Experience Report, or CrUX. It aggregates qualifying real Chrome user visits and uses a rolling time window to reflect historical experience.

According tothe PageSpeed Insights official documentation, its field data usually represents the past 28 days and uses the 75th percentile to judge experience quality. It is not a request just sent from a certain region after you click the “Analyze” button.

This means that even if you completed a CDN migration today and CDNChart already shows the new nodes taking effect, PageSpeed real-user data will not all improve immediately. The old CDN, old front-end versions, and slow visits before migration may still be included in the statistical window.

Also confirm whether PageSpeed is showing:

• URL-level data for the current URL;

• origin-level data for the entire origin;

• mobile device data;

• desktop device data.

If the page has insufficient samples, URL-level field data may be unavailable. The absence of CrUX data does not mean the site is inaccessible or that performance is necessarily poor; it only means there are not enough samples that meet its statistical criteria.

Lab data: answers how the current page performs in a simulated environment

The performance score in the lower part of PageSpeed comes from Lighthouse lab tests. It loads the page under controlled device and network conditions and generates metrics such as FCP, LCP, Speed Index, TBT, and CLS.

Lab tests are better suited to locating problems, such as:

• whether the largest content element loads too late;

• whether JavaScript occupies the main thread for long periods;

• whether first-screen images are too large;

• whether CSS or fonts block rendering;

• whether noticeable shifts occur during page load.

But it is only one or a few page loads under a specific test environment. Server load, ad content, A/B tests, third-party scripts, and changes in network routing can all cause score fluctuations.

If PageSpeed field data and lab data contradict each other, you can refer toGoogle’s explanation of the differences between lab data and field datato make a judgment: field data is better for confirming whether real users are affected over time, while lab data is better for reproducing and debugging specific issues.

Why is CDNChart fast while PageSpeed mobile is slow?

This is the most common set of results.

Suppose CDNChart shows that DNS resolution, connection, and download times in the target region are all low and status codes are normal, indicating that the CDN node and basic request path show no obvious problems. But after the page enters the browser, it may still slow down due to the following factors:

• the hero image on the first screen is not compressed or its loading priority is not set properly;

• the JavaScript bundle is too large, so it executes slowly on low-performance phones;

• CSS, fonts, or synchronous scripts block first render;

• the page depends on many third-party ad, analytics, or customer service scripts;

• first-screen content requires client-side API requests before it can be generated;

• HTML is served from cache, but images, fonts, and scripts are not effectively cached;

• page elements change size after loading, increasing CLS;

• the main thread is occupied by long tasks, resulting in poor TBT or INP.

These problems usually cannot be fully solved by changing the CDN alone. A CDN can shorten static resource transfer and some network wait times, but it cannot automatically reduce JavaScript execution time or fix layout shifts.

Current Core Web Vitals focus mainly on LCP, INP, and CLS. According tothe official Web Vitals metric documentation, evaluation should focus on 75th percentile performance, not just cherry-pick the single best run.

Why does PageSpeed score well while CDNChart still shows slow regions?

The opposite case is also common.

PageSpeed lab tests may run from Google infrastructure in North America, Europe, or Asia, and the exact test location and route may not represent the site’s main users. A fast response from an overseas test environment to an overseas CDN node does not mean users in different provinces and on different carriers in mainland China will have the same experience.

If CDNChart shows any of the following, investigate CDN scheduling, node coverage, cross-network routing, DNS resolution, or access control first:

• China Telecom nodes are normal, but connection time on some China Mobile nodes is clearly higher;

• East China is relatively fast, while many nodes in Northwest and Northeast China are slow;

• the response IPs resolved in different regions vary widely;

• some regions return 403, 5xx, or access failures;

• requests go through multiple redirects;

• slow nodes are concentrated on one carrier.

This is also why online speed tests must select the regions where real users are located. You can first read“Why Should Online Website Speed Tests Use the User’s Region?”, then choose test nodes based on the distribution of business users. For sites serving mainland Chinese users, check China Telecom, China Unicom, and China Mobile separately; for businesses serving overseas users, cover the main countries and regions.

When website speed test results differ, how should you compare them item by item?

An effective comparison is not to open the two pages side by side and see which number is larger, but to troubleshoot in the order of “network entry—server response—resource transfer—browser rendering—real-user experience.”

Step 1: Fix exactly the same test URL

First confirm that both tools are testing the same address, including:

• HTTP or HTTPS;

• www.example.comorexample.com;

• home page or a specific content page;

• whether the URL path and query parameters are identical;

• whether there is a trailing slash;

• whether it redirects to a login page, regional page, or mobile version.

http://example.com,https://example.comandhttps://www.example.com/may go through different numbers of redirects, use different certificates, or hit different CDN configurations. When URLs differ, the numbers that follow are not directly comparable.

We recommend testing the HTTPS address that real users ultimately visit, rather than only testing intermediate redirect domains.

Step 2: Use CDNChart to establish a network and CDN baseline

Put the same URL intothe CDNChart website speed test tool, and select nodes in mainland China across China Telecom, China Unicom, and China Mobile, or overseas nodes, according to the target users. At this point, do not rush to look at average total time; check the following results in order.

1. Whether HTTP status codes are consistent

   Some regions return 200 while others return 403, 502, 503, or time out. This indicates the issue is not just “slow speed”; it may also involve WAF rules, node failures, or origin fetch issues.

2. Whether response IPs meet expectations

   The same domain returning multiple IPs may be normal CDN scheduling. The key is whether slow nodes are concentrated on certain response IPs and whether those IPs are clearly associated with the affected regions.

3. Whether DNS resolution time is abnormal

   If DNS resolution itself takes a long time, page resource optimization cannot eliminate that wait. Continue checking authoritative DNS, recursive resolution paths, CNAME chains, and scheduling configuration.

4. Whether connection time is consistently high

   If connection is slow but download is normal, it is usually more worthwhile to check network distance, cross-network routing, node reachability, and the TCP connection process.

5. Whether download and total time increase only in some regions

   Nationwide slowness and slowness in a few regions call for different approaches. The former may involve the origin, cache policy, or the resources themselves; the latter looks more like a node, carrier, or routing issue.

6. Whether extra redirects occur

   HTTP-to-HTTPS, bare-domain-to-www, regional, and login redirects can stack. Each cross-domain redirect may also repeat DNS, connection, and TLS processes.

CDN test methodology and scoring criteriacan help confirm the test nodes and data definitions. The results here are active probe results, suitable for identifying regional differences and current anomalies; they should not directly replace a company’s own real-user monitoring.

Step 3: Record PageSpeed field data and lab data separately

Do not just copy down a single performance score. At minimum, record the following:

In particular, do not use Lighthouse TBT as a direct substitute for INP in CrUX. Both relate to page responsiveness, but their measurement methods and applicable scenarios differ: TBT comes from the lab page-loading process, while INP comes from real-user interaction experience.

Step 4: Use a cross-reference table to locate the problem layer

The point of this comparison table is to shift from “which tool is more accurate” to “which layer of the problem each tool exposes.”

Use curl to further confirm each request phase

When CDNChart shows abnormal nodes in some locations and PageSpeed cannot explain the network request details, run the following in a representative network environment:

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

Focus on:

• status: final HTTP status code;

• remote_ip: actual connected IP;

• dns: cumulative time when domain resolution completes;

• connect: cumulative time when the TCP connection is established;

• tls: cumulative time when the TLS handshake completes;

• ttfb: cumulative time when the first byte is received;

• total: total time of the entire request;

• redirects: number of redirects.

Most of these curl times are cumulative from the start of the request and cannot simply be added together. For example, the approximate TCP phase duration can be calculated withconnect - dnsto determine it; for the TLS phase, refer totls - connect.

If you need to distinguish between the CDN and the origin, and you have confirmed the origin IP and obtained authorization, you can test the origin while preserving the domain name, Host, and TLS SNI:

curl -sS -o /dev/null \
  --resolve www.example.com:443:203.0.113.10 \
  -w 'status=%{http_code}\nttfb=%{time_starttransfer}\ntotal=%{time_total}\n' \
  https://www.example.com/

Do not replace the URL directly with the origin IP, and do not disable certificate verification to obtain a non-comparable result.--resolveallows requests to connect to a specified IP while preserving the HTTPS domain name and TLS SNI.

If CDN requests are clearly slower than origin requests, check CDN nodes, origin connections, or cache configuration. If the origin’s own TTFB is already high, simply changing CDNs may not solve issues with dynamic pages and uncached requests.

A single test cannot serve as an optimization acceptance conclusion

Whether using CDNChart or PageSpeed, a single test may be affected by temporary routing, node load, cache warm/cold state, and third-party resource changes.

When comparing results before and after optimization, at minimum:

• use exactly the same URL;

• keep the same device type and test entry point;

• repeat tests at different times;

• use the same regional and carrier nodes in CDNChart;

• save the fastest, slowest, average, and failed nodes separately;

• save PageSpeed field data and lab data separately;

• record the test date, release time, and CDN configuration change time;

• do not use one best score to override consistently slow nodes.

For general reasons behind differences between tools, you can also refer to“Why Do Different Speed Test Platforms Show Large Differences for the Same Website?”to continue checking node location, network environment, cache status, and metric definitions.

After obtaining both sets of results, make decisions in this order

If CDNChart finds many failed nodes or obvious carrier differences, address DNS, CDN scheduling, status codes, node reachability, and origin issues first. When users cannot even open the page reliably, optimizing LCP will not solve basic availability.

If CDNChart shows normal requests across regions while PageSpeed LCP, TBT, or CLS is poor, focus on hero images, render-blocking resources, JavaScript execution, fonts, and page layout.

If Lighthouse has improved but CrUX is still poor, do not immediately conclude that optimization failed. First confirm when the change was released, then observe the rolling window of real-user data, and use your own RUM system to break it down by country, carrier, device, and page type.

If both sides are slow, do not rush to only change the CDN or only compress images. Break the problem into DNS, connection, TTFB, download, LCP, main-thread blocking, and interaction delay, and identify layer by layer the stage that consumes the most time.

CDNChart and PageSpeed are not two competing scoring systems. The former helps answer “can users reliably and quickly retrieve content from the correct node,” while the latter helps answer “after the content is retrieved, can the browser quickly render it and respond to interactions.” Only by comparing these two layers along the same access path can inconsistent website speed test results turn from a confusing phenomenon into problems that can be located item by item.