How to Choose a CDN Speed Test Tool: Check Nodes, Metrics, and Result Records First

You enter a domain into a CDN speed test site, wait a few dozen seconds, and the page fills with green; the average response time doesn’t look high either—does that mean the CDN is fast?

Not necessarily.

If the test page doesn’t tell you where the request originated, which carrier was used, which IP it resolved to, how large the file was, what status code was returned, and whether it was a cache hit, that “average speed” is hard to interpret.

It may genuinely mean the site is fast, or it may just reflect a few nodes requesting a very small file, or all the slow nodes being hidden by the average.

When choosing a CDN speed test site, the point isn’t how many green dots appear on the interface; start by checking three things:whether the nodes represent your users, whether the metrics can pinpoint where the slowness is, and whether results can be saved and reproduced.

First, decide what question this speed test needs to answer

Even for “testing website speed,” different goals call for different tools and test targets.

CDN speed testing focuses more on network and delivery performance after requests reach edge nodes from different networks; web performance testing also factors in browser rendering, JavaScript execution, image layout, and third-party scripts.

Both sets of results matter, but one cannot replace the other.

Google’s PageSpeed Insights documentation also clearly distinguishes lab data from field data: lab tests are suited to diagnosis under controlled conditions, while field data is closer to actual experience but has limited metrics and sample scope. SeePageSpeed Insights data documentation.

So before asking “which CDN speed test site is good,” make the question specific. Otherwise, it’s easy to judge CDN routes by a page performance score or judge the entire website experience by one static file’s download speed.

First, look at test nodes: more nodes doesn’t mean effective coverage

Test nodes determine whose experience the results represent. Results from a Beijing China Unicom node can’t stand in for Guangzhou China Mobile, and results from a Singapore cloud server can’t represent ordinary home broadband users in Indonesia.

A site suitable for CDN testing should disclose at least the following node information:

• Country, region, and city;

• Carrier or network type;

• Whether the node is online and its last check time;

• The number of nodes and how many actually participated in this test;

• Nodes that failed, timed out, or returned no results;

• Where possible, provide node ASN or network ownership information.

For a mainly mainland China user base, at least cross-check regions and carriers

If a site mainly serves mainland China users, don’t select nodes only by “Beijing, Shanghai, Guangzhou”; also cover China Telecom, China Unicom, and China Mobile separately in core cities.

For example, fast access from Beijing Telecom doesn’t prove Beijing Mobile is fast; good performance from Hangzhou Mobile doesn’t mean Chengdu Mobile isn’t taking a roundabout route.

Cross-carrier comparisons within the same region often reveal route weaknesses more easily than testing many cities on one carrier.

An initial test scope can include:

• Provinces and cities with the highest user or order volume;

• Representative locations in North China, East China, South China, Central China, Southwest China, Northwest China, and Northeast China;

• China Telecom, China Unicom, and China Mobile in each core region;

• Where there is truly a sizable user base, add China Broadnet, CERNET, or other networks.

Region weights don’t need to be evenly distributed; refer to your own access logs, orders, and user value. For related methods, continue reading “For a mainly mainland China user base, which regions and carriers should you focus on when choosing a CDN?”

For a mainly overseas user base, don’t rely on a single “overseas nodes” category

Overseas is not one network environment. Tokyo, Los Angeles, Frankfurt, and São Paulo differ greatly in distance, carrier interconnection, and cross-border routes.

International-facing sites should choose nodes based on where real users are. For example, if users are concentrated in Southeast Asia, prioritize covering major markets such as Singapore, Japan, Indonesia, Thailand, and Vietnam, rather than calculating a “global average speed” from large numbers of U.S. test results just because North American nodes are easy to obtain.

When a country has multiple major networks, cross-test them as much as possible.

Cloud server nodes that cannot cover local home broadband and mobile networks are only a synthetic probing perspective and cannot fully replace real local users.

Also check how many nodes actually returned results successfully in this run

The page may say “300 nodes worldwide,” but only a subset may have actually completed the test this time.

If the speed test site counts only successful nodes and doesn’t show timeouts and failures, the final average will naturally look good.

So check all of the following:

• Total planned nodes;

• Nodes actually started;

• Number of successes, failures, and timeouts;

• Which regions returned no data;

• Whether failed results are included in availability statistics.

Missing data is itself a result. If a large number of nodes on a given carrier all time out, they can’t simply be deleted from the average.

Second, look at test metrics: total time only shows that something is slow, not why

An HTTPS request generally goes through stages such as DNS resolution, TCP connection establishment, TLS handshake, sending the request, waiting for the first byte, and downloading the response body.

Showing only one “response time” at best tells you how long the request took overall. To determine where the problem occurs, you need more granular metrics.

Chrome DevTools’ Network panel shows request status, protocol, remote address, response size, total time, and a waterfall chart, and lets you view detailed Timing for an individual request.

The official documentation also notes that you can disable the browser cache to simulate a first visit. SeeChrome DevTools Network reference.

A speed test site doesn’t have to provide all the information a browser tool does, but the more complete its DNS, connection, TLS, TTFB, download, status code, and resolved IP data is, the easier it is to pinpoint problems.

Why are P50 and P95 more useful than a single fastest result?

Network performance naturally fluctuates. It’s normal for results from the same node to differ across consecutive tests. Node load, network congestion, DNS caching, TCP connection reuse, and origin status can all affect a single request.

So don’t treat the following results as conclusions:

• The fastest node in this run;

• The national average from one test;

• The lowest latency among all successful requests;

• A “composite speed” with no sample size stated;

• Vendor rankings derived from different times and different files.

P50 can be understood as a fairly typical middle level; P95 is closer to the slower tail requests.

If a CDN’s P50 is good but P95 is noticeably high, it often means it’s fast most of the time but unstable in some regions, time periods, or requests.

When choosing a CDN speed test site, it’s best to confirm whether it provides:

• Sample counts for each region and carrier;

• Percentiles such as P50, P90, or P95;

• Failure and timeout rates;

• Data collection time and statistical period;

• Whether results can be filtered by region, carrier, and time.

If the platform only offers one-off tests, you can run them yourself at multiple times and save the raw results.

Don’t pursue false precision just to produce “absolutely accurate” decimals; the purpose of testing is to find stable differences and anomalous patterns.

Third, look at result records: speed tests that can’t be reviewed are hard to use for decisions

Many speed test results are glanced at once, and by the next day all that’s left is “it seemed pretty fast yesterday.”

By the time the CDN adjusts routes or users complain again, you can no longer find which URL was tested, which nodes were used, or what IP it resolved to.

A CDN speed test site suitable for long-term use should ideally be able to save or export the following:

测试时间和时区
测试URL及最终跳转URL
节点国家、城市和运营商
解析IP及网络归属
HTTP状态码和协议版本
响应大小或测试文件大小
DNS、TCP、TLS、TTFB、下载及总耗时
下载速度
缓存状态
失败原因和错误信息
本轮样本数

If the tool provides share links, history, or CSV/JSON export, it will be better suited for before-and-after onboarding comparisons. If it has no export function, at least save screenshots and record the test conditions separately.

A 200 status code doesn’t necessarily mean the test succeeded

Some sites return an HTTP 200 verification page after being blocked by a WAF; misconfigurations can also redirect non-existent resources to the homepage.

Looking only at the status code can mistake erroneous content for a successful result.

For important tests, also verify:

• Whether the final URL was redirected;

• Whether the response body size matches expectations;

• Content-TypeWhether it is correct;

• When necessary, compare file hashes or content signatures;

• Whether a CAPTCHA, login page, or WAF challenge page was returned.

Especially when testing large files, confirm that the full content was actually downloaded rather than the server returning a tiny error message.

If cache status isn’t separated, CDN speed test results are easily misread

The first request to the same URL may need to go to origin, while subsequent requests may be served directly from edge cache. These two types of requests take different paths and shouldn’t be interpreted together.

For testing, divide scenarios into three groups:

Different CDNs don’t use exactly the same cache response header names. Common HIT, MISS, and Age values can serve as clues, but they should be interpreted alongside vendor documentation.

Not seeing a cache header doesn’t by itself mean caching isn’t being used.

If you need to investigate further, first read “How to read CDN cache hits: understanding HIT, MISS, and Age,” or useCDNChart CDN CheckView a domain’s CNAME, node IPs, and the CDN it may be using.

Test the homepage, static files, or download files? The answer is to test each separately

Testing only the homepage has one obvious problem: the page may request ads, analytics code, fonts, images, and third-party APIs at the same time. It’s hard to tell directly from homepage total time whether the CDN, origin, or third-party resources are slow.

Testing only a small static file isn’t enough either. It can show connection and first-byte behavior, but it poorly represents sustained download capability.

A fairly complete set of test targets can include the following categories.

A page document

Used to observe whether HTML access, redirects, dynamic origin fetches, and the page entry point work properly.

Record the final URL during testing so redirect time isn’t ignored.

A fixed small static file

For example, a CSS, JavaScript, or image file from real business use, to observe node connection, TTFB, and cache hits.

The file should remain unchanged to avoid content and size changes during testing.

A fixed large file

Prepare a public test file of several MB to several dozen MB based on your business, to observe sustained throughput and transfer stability.

If the file is too small, the download may end almost as soon as it starts, and the calculated speed is easily affected by connection establishment and timing errors.

A critical dynamic API endpoint

Test only endpoints that require no sensitive parameters, don’t modify data, and allow public access.

Do not submit login credentials, user tokens, internal addresses, or URLs containing private information to third-party speed test platforms.

These URL types should be measured separately; don’t blend small-file TTFB, page total time, and large-file download speed into one “composite average.”

Comparing two CDNs under the same conditions makes the results meaningful

If you want to compare CDN A and CDN B, at least keep the following conditions consistent:

• Use the same origin or content copy;

• Test file content and size are the same;

• Cache rules, compression, and Range settings are the same;

• Select nodes in the same regions and on the same carriers;

• Use the same timeout criteria and concurrency settings;

• Test within a similar time window;

• Compare warm cache and cold cache separately;

• Use a similar sample size for each test unit.

If A uses a 20 MB file while B uses a 200 KB file; A is tested during evening peak while B is tested in the early morning; or A is all cache HITs while B mostly needs origin fetches, the final numbers can’t be compared fairly.

When you need to shortlist candidate vendors, you can first useCDNChart vendor comparisonTo view data under a consistent methodology, then validate it with your own domain and business files.

Leaderboards are useful for narrowing the field, but they can’t replace a real business trial.

A CDN speed testing workflow you can execute directly

Before testing: lock down the conditions

Prepare the page, small file, large file, and necessary dynamic URLs; record file sizes, cache rules, origin location, test date, and CDN configuration version.

First, use DNS orCDN check toolsConfirm the domain’s current resolution status, to avoid testing while the CNAME hasn’t taken effect or some regions are still accessing old nodes.

Round 1: quickly identify regional and carrier anomalies

UseCDNChart Website Speed Testor other multi-node tools to cover major regions and carriers, and first review success rate, status codes, resolved IP, TTFB, and total time.

This round isn’t for directly choosing the fastest CDN; it’s for finding obvious anomalies: which regions time out, which carrier is slow, and whether traffic is being scheduled to unexpected nodes.

Round 2: repeat tests with fixed resources

For normal and anomalous regions, repeat tests on the same URLs at different times.

Cover at least one off-peak and one peak business period; if users mainly visit in the evening, don’t test only on weekday mornings.

Calculate P50, P95, failure rate, and download speed separately. If the speed test platform lacks percentile functionality, export the raw records and calculate them yourself.

Round 3: pinpoint issues using browser and server-side logs

When multi-node results show high TTFB in a location, then check the browser Network waterfall, CDN logs, and origin logs:

• Slow DNS: check authoritative DNS, the resolution chain, and differences in local resolution;

• Slow TCP or TLS: check the scheduled IP, network path, and protocol configuration;

• Slow TTFB with mostly MISSes: check the origin fetch route and origin processing;

• Still slow on HIT: check the edge node, route, and response body size;

• Low large-file throughput: run sustained tests and rule out origin, rate limiting, and business bandwidth issues.

Round 4: keep a baseline for future retesting

Save results from normal periods.

Later, when changing DNS, cache policies, certificates, HTTP versions, or CDN vendors, retest under the same conditions.

Without a baseline, you only know “today it’s 1.2 seconds,” but you can’t tell whether it’s faster or slower than last week.

Use curl locally for a supplementary record

Multi-node speed testing is good for observing regional differences, while local commands are good for quickly checking a URL’s connection stages, remote IP, and download speed.

curl -L -o /dev/null -sS \
  -w 'status=%{http_code}\nremote_ip=%{remote_ip}\ndns=%{time_namelookup}\nconnect=%{time_connect}\ntls=%{time_appconnect}\nttfb=%{time_starttransfer}\ntotal=%{time_total}\nspeed_download=%{speed_download}\n' \
  https://example.com/test-file.bin

Note that most of these curl times are cumulative from the start of the request to the corresponding stage; they are not independent segment durations that can be directly added together.

For example,time_connectalready includes the preceding DNS time,time_appconnectand also includes the earlier connection process.

This command represents only one result from the network where the machine runs. It can’t replace nationwide or global multi-node testing, but it’s well suited to checking whether the URL, status code, remote IP, and test file are correct.

Score a CDN speed test site this way to decide whether it’s worth long-term use

The following is a sample scoring method for choosing a tool, not an industry standard; adjust it based on your business.

If you’re just doing a temporary check of whether a website opens, the tool doesn’t need every capability; if you’re comparing CDN vendors, adjusting production configurations, or producing monthly reports, methodology documentation and raw result records are very important.

Don’t celebrate these good-looking results too quickly

“The national average is only a few dozen milliseconds”

First check how many successful nodes the average includes, whether failed nodes were excluded, and which stage was tested.

If it only calculates connection time for successful requests, that number can’t represent the full website visit experience.

“The fastest node took only a few milliseconds”

The fastest node may happen to be in the same data center or on the same network as the CDN.

It proves the best-case result for that node, but not the experience of most users.

“All regions return HTTP 200”

Continue checking response size, final URL, and content.

A 200 may return a WAF verification page, the default homepage, or an error message.

“Download speed is especially high”

Check the test file size.

If the file is too small, the download finishes just after the connection is established, and the instantaneous result is unsuitable for evaluating sustained throughput.

“Speed test site A says it’s fast, speed test site B says it’s slow”

First compare node locations, carriers, test times, URLs, cache status, timeout criteria, and statistical methods on both sides.

The two tools observe different network environments, so inconsistent results don’t necessarily mean one of them is wrong.

FAQ

Which CDN speed test site is best?

No single tool is suitable for every purpose.

When choosing, prioritize whether it covers your users’ regions and carriers, whether it provides DNS, connection, TLS, TTFB, download, status code, and resolved IP data, and whether results can be saved for review. Whether the page looks nice is not a primary criterion.

What’s the difference between CDN speed testing and website speed testing?

CDN speed testing focuses more on node scheduling, network connections, cache delivery, and download capability; a complete website speed test also analyzes browser rendering, JavaScript, images, fonts, and third-party resources.

When troubleshooting real issues, the two usually need to be used together.

Are more test nodes always more accurate?

No. Nodes need to match the user distribution and clearly indicate region, carrier, and online status.

A large number of nodes concentrated in non-target markets may increase the sample size while moving conclusions further from real users.

Should CDN speed testing test a domain or a specific URL?

When troubleshooting DNS and node identification, you can start with the domain; when evaluating performance, use specific URLs and separately prepare a page, small static file, large file, and necessary dynamic endpoints.

Entering only the homepage domain makes it hard to pinpoint issues with specific resources.

Why does the same website produce different speed test results each time?

Network congestion, node load, DNS caching, CDN scheduling, cache HIT or MISS, and origin status all cause fluctuations.

Repeat tests under the same conditions and compare P50, P95, success rate, and anomaly distribution rather than expecting identical numbers every time.

Can one speed test result decide whether to switch CDNs?

Not recommended. One result is good for finding clues, but insufficient to prove long-term performance.

First useCDNChart Website Speed Testto identify anomalous regions and carriers, then use fixed files across multiple time periods for repeated validation, combining CDN logs, origin logs, and real user data.

Only when different tools, multiple time periods, and real user data all point to the same issue is it more appropriate to move on to configuration optimization, vendor discussions, or a small-traffic switch test.