CDN Speed Test vs. Website Speed Test: What's the Difference and What Can Each Measure?

When a website is slow to load, many people's first instinct is to run a speed test tool.

But once you actually open the tool, another issue appears. Some pages show CDN latency, availability, and throughput; others show DNS lookup, connection, and download time; still others provide LCP, CLS, INP, and a long list of front-end optimization suggestions.

They all call themselves “speed tests,” but they are not testing the same thing.

Here is the short version: a CDN speed test looks at how well the content delivery network performs across different regions and network paths; a website speed test looks at how a real domain or page can be accessed. If you want to know when the full page becomes visible to users and whether they can interact with it smoothly, you also need browser-level page load testing.

So, strictly speaking, the speed tests we usually mention can be divided into at least three types:

Once these three test types are separated, many results that look contradictory start to make sense:A CDN may rank fast while the website is still slow; a URL may respond quickly while the complete page is still slow to appear.

A CDN speed test measures the content delivery network itself

If your question is “Which CDN is faster?”, “How do Cloudflare and CloudFront compare?”, or “Which CDNs should users in China test first?”, what you should look at first is CDN performance tests.

These tests usually try to control test conditions. For example, different CDNs are asked to serve the same or nearly identical test files, requests are continuously sent from different regions, and results are summarized according to a consistent rule.

This is intended to reduce interference caused by differences in file size, test time, and statistical methods.

In CDNChart'sGlobal CDN RankingsandCDN Vendor Comparison, common metrics include:

• P50 latency:the latency for half of the samples is below this value, giving a view of typical access performance;

• P95 latency:95% of samples have latency no higher than this value, making it easier to catch slow requests and tail-end experiences;

• Availability:the percentage of requests that complete successfully during the test period;

• Throughput:how much data can be transferred per unit of time, particularly useful as a reference for images, video, and large-file downloads;

• Regional and carrier performance:whether the same CDN shows obvious differences in different regions and networks;

• Sample size and update time:how many observations these findings are based on, and whether the data is still up to date.

CDN speed tests are suitable for side-by-side comparisons, but they cannot directly answer “why is my homepage slow to open?”

The reason is simple: a standardized test file is not your real website. Your caching rules, origin speed, page code, image sizes, and third-party scripts will not automatically improve just because a CDN performs well in a benchmark.

CDN performance rankings are more useful forbuilding a shortlistthan for directly replacing live-site testing.

For more on how CDNChart unifies test targets, uses P50/P95, and processes samples, seeActive Probing MethodologyandReview Methodology.

Website speed tests: first decide whether you are measuring “a single request” or “the full page”.

“Website speed test” is the term most likely to be misunderstood.

Some website speed test tools measure the HTTP request process for a domain or URL; others launch a real browser or simulate one to load HTML, CSS, JavaScript, images, fonts, and third-party resources.

Both test a website, but they produce different conclusions.

Let's look at the first type: multi-region HTTP speed testing.

InCDNChart Website Speed Test, enter a real domain name to send requests from China Telecom, China Unicom, China Mobile, and overseas probe locations, and view information such as DNS resolution, connection, download time, and response IP.

It is useful for answering these questions:

• Whether the same website has similar access speeds in different regions;

• whether a site that works well on China Telecom is noticeably slower on China Mobile or China Unicom;

• whether the response IP returned in different regions changes after the site is connected to a CDN;

• whether a region's slowness is caused by DNS resolution, connection, or resource download;

• whether there are regional failures, timeouts, or abnormal status codes.

This type of result tests a single specific request. Because it is affected by the target URL, test region, carrier, cache state, and test time, it is best to use the same URL, record the time, and repeat the test several times.

If the homepage is tested first and a cached image is tested second, the two sets of results cannot be directly compared. A test during evening peak hours and a test in the early morning cannot simply be used to calculate “how much faster it became after connecting to a CDN.”

Full-page speed tests focus on how users see and interact with the page

Completion of an HTTP request does not mean the web page is ready to use.

After the browser receives the HTML, it may continue to request dozens or even hundreds of resources. JavaScript needs to be downloaded and executed, images need to be decoded, fonts can block text from displaying, and advertising, analytics, and customer-service components can also slow the page down.

At this point, use the browser's Network and Performance tools orGoogle PageSpeed Insightsto run a full-page test.

Google's documentation for PageSpeed Insights says it reports page experience separately for mobile devices and desktop devices and offers optimization suggestions. The results may include lab-based testing and, when enough data is available, real-user experience information. Seethe official PageSpeed Insights documentationfor details.

Full-page performance tests usually focus on:

• LCP:roughly when the page's main content becomes visible;

• CLS:whether the page shifts unexpectedly during loading;

• INP:whether the page responds promptly when real users interact with it;

• Request waterfall:when each resource starts, how long it waits, and how long it takes to download;

• Number and size of resources:whether the page loads too many scripts, images, or fonts;

• Blocking and execution time:when the network has already responded but the browser is still busy executing JavaScript.

LCP, INP, and CLS are the current Core Web Vitals, reflecting load, interaction, and visual stability, respectively.For metric definitions, see web.dev’s Web Vitals documentation.

Browser load testing is well suited to diagnosing cases where the speed test shows a fast response but users still think the page is slow.

The Network waterfall in Chrome DevTools lets you see the order of different requests, response headers, size, and time taken. For operating instructions, seethe official Chrome Network documentation.

A concrete example: why a CDN is fast but the website is still slow

Suppose a CDN performs well in P50 latency in a standardized test, and your website's multi-region HTTP speed test shows no obvious connection problems, but the homepage still takes several seconds to fully display.

At this point, switching CDN providers alone may not solve the problem.

The real cause could be:

• The homepage HTML is not cached, and each visit has to wait for the origin to generate it;

• above-the-fold images are very large and are not compressed or served in a suitable format;

• there are too many JavaScript files and they run before the page is rendered;

• the page calls third-party analytics, advertising, or customer-service services that respond slowly;

• font files load late, so text stays unstable on screen for a long time;

• the CDN cache is not hit, and requests still frequently go back to the origin.

CDN speed tests can show part of the delivery-layer behavior, multi-region HTTP speed tests can help locate the region or phase where requests are slow, and full-page browser tests can identify exactly which resource, script, or rendering step is slowing the page down.

These three types of tests are not substitutes for one another; they narrow down the problem layer by layer.

Which test tool should you use? Start with the question you want to answer.

If you just need a quick guide, remember one sentence:

When choosing a CDN, compare CDN speed tests under the same conditions; when checking regional access, test your own real domain; when diagnosing a slow page, look at the complete page-loading process.

You can also quickly inspect a single HTTP request without a web-based tool

On macOS or Linux, use curl to check the basic timing of a URL:

curl -sS -o /dev/null \
  -w 'DNS: %{time_namelookup}s\nTCP: %{time_connect}s\nTLS: %{time_appconnect}s\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n' \
  'https://www.example.com/'

Replace the example URL with your own real URL when running it.

The values shown are cumulative checkpoints measured from the start of the request, not independent stages that can be added together.

For example,time_starttransferthe value represents the time from the start until the first byte is received and already includes DNS lookup, connection, and server processing. For field definitions, seethe official curl manual.

This command is convenient for quickly comparing the same URL at different times, but it represents only the network of the device running the command, and it does not execute the page's JavaScript.

A more reliable, combined testing approach

If you are troubleshooting website speed, follow this sequence:

1. Identify the test target.Separately prepare the homepage URL and a public static resource that should be cached by the CDN. Do not combine their results;
   

2. Run a multi-region HTTP speed test.In CDNChart, test the real domain, and record the region, carrier, response IP, time spent at each stage, and any failures;
   

3. Inspect browser requests.Use Chrome Network to reload the page and find resources that have long wait times, large sizes, or fail to load;
   

4. Review page experience.Use PageSpeed Insights or your own real-user monitoring to view LCP, CLS, INP, and optimization suggestions;
   

5. Change only one major condition at a time.After adjusting caching, compression, or page resources, retest with the same URL, at a similar time, and from the same test locations;
   

6. Keep failed and slow requests.Don't only screenshot the fastest result. Record continuously to make it easier to see whether the problem is consistent.
   

If you have just connected to a CDN, first confirm that DNS resolution, request paths, and cache behavior match expectations.

Once the previous article “Has CDN acceleration taken effect? How to check after enabling it” is officially published, add the corresponding internal article link here.

A few commonly confused questions

Does a fast ping mean the website loads quickly?

No.

Ping mainly reflects ICMP round-trip time. It does not handle HTTPS negotiation, wait for server responses, download page resources, or execute JavaScript. Some networks also restrict ICMP, so ping can only serve as a clue about connectivity and latency.

The speed test results look good, so why do users still say the site is slow?

First verify the users' region, carrier, device, access time, and the specific page they are visiting.

Your test may have hit a cached response, while users may have hit a cold cache. You measured the homepage's HTTP response, but what users feel may be page jank caused by a third-party script.

If a CDN ranks high in speed tests, does that prove it is suitable for my website?

No.

Rankings can help you build a shortlist, but you still need to test your own files, domain, cache rules, and primary user regions. Pricing, ICP filing, technical support, and security requirements should also be considered.

Is it enough to run a speed test only once?

Usually not.

Networks fluctuate by region, carrier, and time. When troubleshooting, at least keep the test target consistent and run multiple tests. For a formal vendor selection, cover the primary regions and business peak hours.

Speed testing is not about producing a smaller-is-better number

The biggest danger in speed testing is not too little data, but using the wrong data to answer a question.

If you want to compare CDN vendors but rely only on your complex homepage; if you want to troubleshoot page rendering but stare only at one total HTTP time; if you want to prove that things became faster after connecting to a CDN but did not record the test conditions before the change—then even many numbers will not make it easy to draw a conclusion.

A more effective approach is to first ask:Am I trying to compare CDNs, check a real domain, or troubleshoot a full page?

If you want to see how a website actually behaves across different regions and carriers, openCDNChart Website Speed Test, enter your own domain, and complete a multi-region speed test.

Record the URL, time, and test scope this time, and then run the next comparison under the same context. Only then will the results be truly useful.