Website Speed Testing: How Do You Confirm a CDN Switch Actually Made Your Site Faster?

After switching CDNs, many people open their website and refresh it a few times, feel that pages load more smoothly than before, and conclude that the migration was successful.

This way of judging success is highly prone to error.

The browser may be reusing DNS, connections, and local cache; the new CDN's edge cache may not be warmed up yet; your computer represents only your current city and ISP; and during DNS propagation, some users are still accessing the old CDN. Even refreshing ten times in a row cannot show whether users across the country or overseas are actually experiencing faster access.

To confirm whether switching CDNs was effective, the key is not to "run a test once after cutover" but to establish before-and-after data under conditions that are as consistent as possible:

Use the same domain, same resources, same regions and ISPs, and repeat tests during similar business hours. Then compare success rates, response IPs, resolution time, connection time, download time, total time, and real user experience.

Only then can you distinguish changes brought by the CDN from those caused by caching, traffic, origin load, and network fluctuations.

Why is it not enough to conclude success just because your own access is faster after switching CDNs?

A single local access is affected by at least the following factors:

• Whether the current network is China Telecom, China Unicom, or China Mobile;

• How far the city is from the CDN node;

• Whether DNS is still caching the old result;

• Whether the browser is reusing an existing connection;

• Whether page resources are already in the local cache;

• Whether the CDN edge node has a cache hit;

• Whether the origin server was under high load during the test;

• Whether the page redirects;

• Whether the current access is hitting the old CDN or the new CDN.

For example, a site owner in Shanghai on a China Telecom broadband connection may indeed see faster local access if the new CDN happens to perform well on East China Telecom routes. But users in Northeast China on China Mobile, Southwest China on China Unicom, or overseas users may be routed to more distant nodes, making their overall experience worse.

Therefore, the first question after CDN migration should not be "Is my own access faster?" It should be:

• Are users in core regions seeing faster access?

• Have the ISPs that were previously slow improved?

• Has the slowest group of requests become faster?

• Have the failure rate and error status codes increased?

• Have dynamic pages, images, and downloadable resources all improved?

• Has the new CDN sacrificed certain regions in exchange for a lower overall average?

Before switching CDNs, save an old-CDN baseline first

If DNS has already been fully switched, testing the old CDN will often depend only on previously saved screenshots or monitoring data. The correct order is to test the old CDN first, then carry out the migration.

The baseline test should cover at least four types of objects.

Do not change the test resource on the fly. If the old CDN was tested with a 200KB image and the new CDN with a different 3MB image, the two sets of results are not comparable.

Also record the following at the time:

• Test date and time;

• Domain and specific resource;

• DNS records and CNAME;

• Response IP;

• HTTP status code;

• Resolution, connection, download, and total time;

• Number of redirects;

• Failed nodes;

• Cache status;

• Website traffic and origin load at the time.

If conditions permit, cover at least one daytime period, one evening peak, and one normal business period before migration. For websites with obvious traffic fluctuations, also cover weekdays and weekends.

Use CDNChart to establish multi-region comparisons before and after migration

Before switching CDNs, enter your actual business domain intothe CDNChart website speed test tooland review results separately for China Telecom, China Unicom, China Mobile, Hong Kong, Macao, and Taiwan, and overseas monitoring.

Current speed test results can show monitoring points, response IPs, IP locations, HTTP status, resolution time, connection time, download time, total time, redirects, and failed nodes, and provide fastest, slowest, and average results. This makes it suitable for identifying regional and ISP differences.

When testing, it is advisable to retain the following data sets:

旧CDN测试时间：
测试域名：
中国电信平均结果：
中国联通平均结果：
中国移动平均结果：
核心海外地区结果：
失败节点数量：
主要响应IP：
异常状态码：
最快节点：
最慢节点：

After the new CDN is integrated, retest during a similar time window using the same domain, and record results by the same region and ISP categories.

CDNChart currently mainly provides single-run, multi-node observations, so during a migration project you should proactively save each round of data or screenshots. Do not assume that one speed test represents long-term performance before and after migration.

After cutover, first confirm: are users really accessing the new CDN?

Completing the DNS change does not mean all users immediately reach the new CDN.

Local DNS, ISP recursive DNS, browsers, and operating systems may all continue to cache old records. Some regions may already access the new CDN while others still connect to old nodes. If all results are averaged together at this point, it can lead to misjudgment.

After cutover, first compare:

• Whether the CNAME already points to the new CDN;

• Whether the response IP has changed;

• Whether different regions still return old CDN nodes;

• Whether IPv4 and IPv6 are switched at the same time;

• Whether the apex domain andwwwuse the same entry point;

• Whether images, static resources, and API subdomains have all been migrated;

• Whether HTTP response headers still contain old CDN characteristics.

If the speed test results contain both old and new response IPs, the migration is still in the propagation period. You can continue to observe, but should not immediately conclude that "the new CDN is faster" or "the new CDN is slower."

How can you test the new CDN in advance without changing public DNS?

When the new CDN has the domain and HTTPS certificate configured but public DNS has not yet been switched, you can use curl--resolveto specify a test IP for the new CDN:

curl --resolve www.example.com:443:203.0.113.10 \
  -o /dev/null -sS \
  -w 'status=%{http_code}\nremote_ip=%{remote_ip}\ndns=%{time_namelookup}s\nconnect=%{time_connect}s\ntls=%{time_appconnect}s\nttfb=%{time_starttransfer}s\ntotal=%{time_total}s\nsize=%{size_download}\nspeed=%{speed_download}\n' \
  https://www.example.com/

This commandwww.example.comtemporarily connects to the documentation example address203.0.113.10. In actual testing, replace it with the test IP provided by the new CDN for that domain.

Unlike accessing the IP directly,--resolvepreserves the domain in the URL, so the HTTP Host and TLS SNI remainwww.example.com, making it better suited for validating HTTPS sites. curl's officialHTTP request script documentationalso uses it--resolveto connect a specified hostname to a specific IP in development or test scenarios.

Note the following:

• The new CDN must already have the domain bound;

• The edge node must have the matching certificate installed;

• The specified IP must be able to serve that domain;

• A single-IP test cannot represent the CDN's real DNS scheduling;

• This method is suitable for validating nodes and configuration, not for replacing nationwide multi-region speed tests.

To confirm that a website is truly faster, which metrics should you compare?

1. Success rate must not decrease

Speed improvements must be based on successful requests.

If the new CDN's average time decreases but 403, 502, 503, 504, TLS failures, or timeout nodes increase, the migration cannot be considered successful. For e-commerce, API, login, and payment services, success rate is usually more important than average speed.

At minimum, compare:

成功节点数
失败节点数
HTTP 4xx数量
HTTP 5xx数量
TLS或连接失败数量

An occasional failure at a single node may be temporary network jitter; consecutive failures across multiple rounds in the same region and ISP should be prioritized.

2. Do not compare only the fastest node

The fastest node usually represents the most ideal access conditions, but not necessarily the main users.

More valuable comparisons include:

• What changes have occurred for China Telecom, China Unicom, and China Mobile respectively;

• Whether core user provinces have improved;

• Whether the slowest nodes have become faster;

• Whether failed nodes have decreased;

• Whether target overseas countries have improved;

• Whether slow nodes are concentrated on a particular response IP;

• Whether the fluctuation range across multiple test rounds has narrowed.

If conditions permit, aggregate multiple rounds into median and P95. The median reflects typical access, while P95 reflects the slower set of requests. CDNChart's speed test pages provide node-level results and fastest, slowest, and average data; median and P95 can be calculated separately from multiple rounds saved during migration. A single average should not be mistaken for complete percentiles.

3. Has resolution time changed?

Switching CDNs usually involves changing CNAMEs and the DNS scheduling chain.

If the new CDN's node connections are faster, but the CNAME chain becomes longer or authoritative DNS is unstable, total time may not decrease. Check:

• Whether resolution time has increased overall;

• Whether resolution is noticeably slower for a particular ISP;

• Whether the CNAME has unnecessary multi-level hops;

• Whether old and new DNS TTLs affect the switch;

• Whether IPv4 and IPv6 resolution are consistent;

• Whether overseas recursive DNS can obtain results reliably.

Immediately after migration, DNS cache hit conditions differ, so resolution time may fluctuate in the short term. Wait until propagation is relatively stable before making a formal comparison.

4. Has connection time decreased in target regions?

Connection time better reflects the network distance, routing, and packet loss between users and CDN edge nodes.

If connection time for East China Telecom decreases after switching CDNs but rises significantly for Northeast China Mobile, the new solution is not simply "faster" or "slower"; rather, regional coverage and ISP routes have changed.

At this point, refer back to the real user distribution. If Northeast China Mobile accounts for a high share of business traffic, this degradation cannot be masked by the national average. If there are almost no users in that region, its decision weight can be reduced, but you should still watch for widespread failures.

5. Have download time and throughput improved?

For image sites, download sites, video, and software distribution businesses, it is not enough to look only at whether connections are fast.

For small files, total time may be mainly consumed by DNS, connection setup, and server-side wait; large files depend more on node egress bandwidth, route congestion, and sustained throughput.

Before and after migration, use the same file and ensure:

• The file content and size are identical;

• The compression method is identical;

• The Range request policy is identical;

• One version is not cache-hit while the other is origin-fetched;

• WAF, authentication, or hotlink protection does not return different content.

If the new CDN has a faster time to first byte but slower large-file download speeds, this may not be an improvement for a download business.

6. At which stage does total time decrease?

It is not enough to know that total time has decreased; you also need to know where the change comes from.

CDN performance improvement is not about attributing all time savings to "faster nodes"; it is about identifying what changed in DNS, connections, caching, origin fetch, and download.

Cold cache and warm cache must be tested separately

The old CDN has been running for a longer time, so popular resources are usually already in edge cache. When the new CDN has just been switched, its cache has not yet been built, and many requests may need to go to the origin.

If you directly compare old CDN warm-cache results with new CDN first-access results, the results are inherently unfavorable to the new CDN; conversely, testing only after the new CDN is warmed up may fail to show real cold-cache and origin-fetch capability.

It is advisable to record separately:

• First request or cache MISS;

• Cache HIT after consecutive requests;

• Revalidation after cache expiration;

• Dynamic requests that must not be cached;

• First distribution of new resources after a major promotion or release.

Do not keep only the fastest round just to make the data look good. CDN migration requires looking at both warm-cache delivery speed and whether the origin can withstand origin-fetch pressure when there is a cache miss.

How can you avoid inconsistent test conditions before and after migration?

The most common misjudgment is not caused by inaccurate tools but by changed test conditions.

Before and after migration, keep the following as consistent as possible:

• Same domain;

• Same URL and file size;

• Same test regions;

• Same ISPs;

• Similar test time windows;

• Same request method and headers;

• Distinguishable cache status;

• Same origin version and configuration;

• No large-scale changes to third-party resources on the page.

If you also change image formats, enable compression, upgrade servers, adjust databases, and rewrite front-end code during migration, then even if the website is noticeably faster, you cannot calculate how much the CDN alone contributed.

You can optimize, but roll out changes in stages and keep records; otherwise, in the end you will only know that "overall performance improved" without knowing which change had an effect.

If website speed tests get faster, does that necessarily mean real users are faster?

Not necessarily.

Multi-node active testing can establish a unified, repeatable network baseline, but it cannot fully reproduce each user's device, browser, mobile network, page behavior, and local cache state.

web.dev'sThe Difference Between Lab and Field Datanotes that controlled testing is suitable for keeping conditions consistent and locating problems, while field data comes from real users' devices, networks, and geographic environments. Both types of data are valuable for performance evaluation.

Therefore, after formal migration you should also monitor real user data:

• Whether LCP has improved;

• Whether page load failure rates have decreased;

• Whether both mobile and desktop have improved;

• Whether experience is consistent across countries and ISPs;

• Whether API error rates and timeouts have increased;

• Whether conversion, bounce, or key business completion rates are abnormal.

Google'sCore Web Vitalsdocumentation uses LCP to measure loading performance, INP to measure interaction responsiveness, and CLS to measure visual stability. These page experience metrics cannot be fully replaced by a single HTTP request speed test.

Active speed testing tells you "what happened to network delivery"; real user monitoring tells you "what users ultimately experienced."

A migration comparison table you can use directly

Do not prefill fixed thresholds in the table below; instead, record them based on the website's original performance and business requirements.

If you are still unsure how to organize tests across regions and ISPs,How to Test Website Speedthe core method is to first select nodes based on user distribution, then narrow down using status codes, response IPs, and stage-by-stage timing.

CDNChart is suitable for multi-region active probing and anomaly detection before and after migration. The platform's data sample thresholds, regional coverage, and known limitations can be checked throughCDN Test Methodology and Scoring Criteria. The final decision on whether to switch all traffic should still be based on real business monitoring, CDN logs, origin load, contract costs, and POC results.

Frequently asked questions

How long should you wait after switching CDNs before running speed tests?

You can test configuration and availability immediately after cutover, but formal performance conclusions should wait until DNS propagation in major regions is relatively stable and should cover at least one full business cycle. For websites with obvious traffic differences, it is best to observe multiple peak and off-peak periods.

If the new CDN is faster on average but slower in some regions, should you switch?

It depends on the real user share and business importance of those regions. If there is obvious degradation in core markets, it cannot be offset by the national average; slight changes in non-core regions can be judged together with cost, stability, and coverage.

Why is the new CDN sometimes slower right after switching?

Common reasons include edge cache not yet warmed up, DNS still propagating, first requests needing to go to the origin, new node connections not yet reused, or incomplete configuration of origin Host, HTTPS, and cache rules.

Is testing only the website homepage enough?

No. The homepage may be a dynamic page, while images, JavaScript, downloadable files, and APIs may use different domains, cache rules, and origin fetch paths. At minimum, cover the homepage, static resources, medium-sized files, and key dynamic APIs.

Can lower ping prove that a CDN is faster?

No. Ping mainly reflects ICMP round-trip latency and does not include DNS, TLS, HTTP processing, cache origin fetch, or content download. Some CDN nodes may also rate-limit or not respond to ICMP.

Should you clear the browser cache before comparing?

When testing with a browser, you can record first access and cached access separately, but network comparisons before and after switching CDNs should preferentially use multi-node HTTP tests or curl. Clearing only the browser cache still cannot control differences in DNS, ISP, and node scheduling.

Can CDNChart directly compare historical results of old and new CDNs?

The current website speed test mainly provides multi-region and ISP results for a single task. Before and after migration, you should proactively save test times, node results, and screenshots, then compare under the same conditions. Do not assume the platform automatically performs long-term historical comparisons.

What indicates that switching CDNs has not solved the problem?

If connection time decreases but dynamic pages and APIs remain slow, the problem may mainly lie in origin processing, databases, or the origin fetch path; if all CDN tests are normal but pages remain slow, continue checking images, JavaScript, third-party resources, and browser rendering.