Does CDN Acceleration Actually Work? How to Test It and Check Your Website’s CDN Speed

After a website is put behind a CDN, the fact that pages load doesn’t mean CDN acceleration is doing its job. Some sites have changed their DNS records and requests do go through the CDN, but static assets never hit cache and have to go back to origin every time. Others have no problem with CDN setup itself, but node scheduling, origin routes, or slow origin responses mean real-world access speed hasn’t improved much.

To tell whether CDN is working, you can’t just look at “can the site be accessed?” or a single Ping result. A more reliable approach is to check DNS resolution, response headers, cache status, TTFB, and access speed across multiple regions.

1. How do you confirm CDN acceleration is working?

Many site owners set up CDN and immediately open the site to take a look. The site loads, images show up, and they assume CDN is configured correctly. From a setup standpoint, that does mean nothing is badly broken. But to answer “is CDN acceleration actually working?”, you need to dig deeper.

Generally, you can break it down into three levels:

In other words, putting a site behind CDN is only step one. For CDN acceleration to be truly effective, user requests should first reach an edge node close to the user, cacheable content should be returned directly from that node, and the distance and number of trips to origin should be reduced. If requests go through CDN but still hit origin every time, CDN’s caching benefit is limited.

2. First, check whether the site is actually using CDN

The first step is DNS.

Most CDNs ask you to point your domain to a CDN-provided address via CNAME or another DNS method.

For example, originally:

www.example.com → origin IP

After CDN:

www.example.com → CDN-provided CNAME → CDN node

If the domain still resolves directly to the original origin IP, check whether CDN setup was completed.

But this is only a first-level check.

Different CDNs have different network architectures and onboarding methods. Some proxy CDNs, Anycast networks, or services that hide node information can’t be judged simply by whether the resolved IP is the origin IP.

So even if DNS looks fine, you still need to inspect actual requests.

3. Check HTTP response headers to see whether requests go through CDN

A more direct method than DNS is to look at HTTP response headers.

In Chrome, open the target site, press F12, go to the Network panel, refresh the page, click the main document or a static asset, and check Response Headers.

You can also use curl:

curl -I https://www.example.com/

Different CDNs return different headers. Common fields include:

Age
Via
X-Cache
Cache-Status

Some CDNs also add their own node ID, cache status, or request ID.

If the response headers clearly show CDN node, proxy, or cache information, the request is very likely going through the CDN network.

That said, not every CDN exposes this information.

Some providers hide node headers, so not seeing X-Cache or Via doesn’t automatically mean CDN isn’t working.

HTTP headers are better used as a supporting check, ideally combined with cache status and multi-region speed tests.

4. To judge whether CDN is really speeding things up, focus on cache hits

This is the most important step.

Just because a request goes through CDN doesn’t mean the content is served from CDN cache.

Suppose a user requests an image.

If the file is already cached at the edge node, the path is roughly:

User → CDN node → User

The CDN can return the file directly.

But if the current node doesn’t have it cached, the path becomes:

User → CDN node → origin → CDN node → User

That adds an origin pull.

Common cache statuses include:

For static assets like images, CSS, and JavaScript, if repeated requests still show MISS, it’s worth checking cache configuration.

Common causes include:

• Cache-Control set incorrectly

• Files configured not to cache

• Requests carrying special cookies

• URL query parameters changing the cache key

• CDN cache rules not covering that directory

• Cache TTL set too short

Normally, a cacheable static asset may be MISS on the first request. After the node pulls from origin and caches it, the next request may become HIT.

That’s why you shouldn’t test CDN by visiting once and calling it done.

5. How do you test whether CDN actually made things faster?

Once you’ve confirmed CDN is handling requests and caching works, the next step is to compare real performance.

Don’t just look at Ping.

More useful metrics include:

• TTFB

• HTTP response time

• Static asset download time

• Access speed in different regions

• Differences across ISPs

1. Compare TTFB

TTFB, or Time to First Byte, is the time from starting a request to receiving the first byte.

For cacheable content, a CDN cache hit usually reduces origin wait time, so TTFB often drops noticeably.

For example:

Direct to origin: TTFB 680ms
CDN MISS: TTFB 520ms
CDN HIT: TTFB 110ms

That’s a meaningful difference.

It shows the CDN edge cache is what made the first byte faster.

But if direct origin is 180ms and CDN is 200ms, you can’t insist speed improved just because CDN is in use.

Whether CDN actually helps still comes down to real test data.

2. Compare static asset download time

Besides TTFB, test images, JS, CSS, or downloadable files.

These are usually good candidates for CDN caching and make it easier to see the edge node’s real acceleration effect.

For example, for a 5MB file hosted in the US, if an Asian user accesses it through a nearby CDN node, a cache hit will usually be far more stable than a direct cross-border request to origin.

The improvement is especially clear for sites whose origin is far from users.

6. Use Chahu for multi-region website speed tests to check CDN scheduling

Testing only from your own computer represents one region and one ISP.

One of CDN’s main values is letting users in different regions reach a more suitable node.

So to judge whether CDN is really working, you need multi-region test results.

You can use Chahu to run website speed tests and see how the site performs across different regions and ISPs.

Don’t stare only at the fastest node. Look at the overall distribution.

For example:

If only your own region is fast and other regions are generally slow, you can’t say CDN overall is doing well. If results across regions are stable and faster than before CDN, that’s stronger evidence that node coverage and scheduling are working.

7. Why isn’t the site noticeably faster after using CDN?

This is very common. CDN doesn’t automatically make every page faster.

1. You’re testing dynamic pages

CDN speeds up static resources like images, JS, CSS, video, and downloads most easily.

But dynamic content like login pages, shopping carts, member centers, and real-time APIs usually needs to hit origin in real time.

If you happen to test a dynamic HTML page, the request still has to be processed by origin, so acceleration may be less obvious than for static assets.

2. Cache never hits

If static assets are MISS on every request, the CDN node has to keep fetching from origin.

Requests may go through CDN, but the edge cache advantage isn’t being used.

In that case, check cache rules first instead of switching speed-test tools.

3. Users are already close to origin

If origin is in Shanghai and the tester is also in Shanghai, and latency was already low, CDN may not produce a dramatic difference.

CDN’s advantage is usually clearer across regions, across ISPs, or when users are far from origin.

4. CDN node scheduling is poor

Normally, users should be sent to a nearby node with good network quality.

But if CDN scheduling is abnormal and sends users to a farther node with worse routes, you may see:

Slower performance after enabling CDN.

This is hard to spot with local testing alone. Multi-region tests are more useful.

5. Origin itself responds too slowly

CDN shortens the distance between users and edge nodes, but it can’t automatically fix all origin performance problems.

For example, if a dynamic page must hit origin every time and origin takes 1.5 seconds to process the request, CDN can only wait.

What really needs optimization is server performance, backend code, database, APIs, and page caching, not just more CDN node tweaking.

6. The real bottleneck is front-end resources

Another case: CDN is working and TTFB is low, but the page still feels slow.

For example:

• Images are too large

• JavaScript takes too long to execute

• CSS blocks rendering

• Third-party ads load slowly

• Font files are too large

These aren’t CDN effectiveness issues.

So a faster TTFB doesn’t guarantee the whole page will finish loading immediately.

8. Which metrics matter most when testing CDN speed?

CDN speed testing isn’t about one number. Useful metrics fall into several categories:

Ping is the most misused. A low Ping only means round-trip latency from the current network to a certain IP is low. It doesn’t directly prove: the site cache hit; HTML responds quickly; images download quickly; CDN origin pull is normal; page load speed has improved. So when judging CDN acceleration, Ping can be part of the picture, but not the whole picture.

9. Troubleshooting order for checking whether CDN acceleration works

If you don’t want to look at everything at once, follow a fixed order.

Step 1: Check DNS

Confirm the domain has been resolved according to CDN requirements. If it still goes directly to origin, later tests are meaningless.

Step 2: Check HTTP response headers

See whether requests go through CDN nodes and whether there’s cache, proxy, or node information.

Step 3: Test static asset caching

Pick cacheable resources like images, JS, and CSS, and request them several times.

Watch for:

MISS → HIT

Does it happen normally?

Step 4: Compare TTFB

Check first-byte time for cache hits and origin pulls separately.

If HIT is clearly faster than MISS, edge caching is doing real work.

Step 5: Run multi-region speed tests

Use results from different regions and ISPs to see whether CDN scheduling is reasonable.

Don’t only test locally.

Step 6: Compare with origin or pre-CDN data

Finally, answer the most important question: after CDN was enabled, did users actually get faster access? Only a before-and-after comparison can show CDN’s real effect, rather than just confirming “configuration is complete.”

Summary

To judge whether CDN is working, don’t just check whether the site opens or whether DNS was changed. Truly effective CDN acceleration should at least meet a few conditions: requests go through CDN nodes, static assets can hit cache normally, and users in different regions see improved real-world access speed.

If CDN is enabled but speed test results haven’t changed much, keep troubleshooting from cache HIT/MISS, TTFB, origin pull time, and multi-region results. When cache HIT is fast and MISS is slow, focus on origin and origin pull. If only some regions are slow, look at node scheduling and routes. If TTFB is already low but pages still feel slow, turn your attention to front-end resources like images, JS, and CSS. Whether CDN is actually useful ultimately depends on real data, not just the fact that “CDN is turned on.”

Related Q&A

Q1: Why does speed testing feel slower right after putting the site behind CDN, compared with connecting directly to origin?

This usually happens because the CDN node hasn’t built a local cache yet (First Visit / Cold Cache), or the origin pull route is far away. On the first request, the edge node has to pull the resource from origin, adding both “user → CDN node” and “CDN node → origin” latency. After the node successfully caches the resource, response time and TTFB on the next test will usually drop significantly.

Q2: Why do images and JS/CSS already show HIT cache, but the page still takes a long time to load in the browser?

A static asset cache hit only solves the transfer layer. If the main document (HTML) contains many unoptimized render-blocking resources — such as third-party scripts that aren’t loaded asynchronously, huge uncompressed images, or critical CSS that hasn’t been extracted — or if the DOM structure is too complex, the browser will still stutter while parsing and rendering the page.

Q3: In cross-border access, how do you verify whether CDN Anycast node scheduling is really sending users to the nearest node?

You can use chuhu’s multi-node network diagnostic tool or a global Ping tool to see which CDN IP ranges are resolved by nodes in different countries. Then check Traceroute hop counts and round-trip latency. If probes in Europe, the Americas, and Asia all connect to backbone nodes in their respective regions nearby, and there’s no detouring (for example, an Asian node isn’t routed through the US), Anycast scheduling logic is working normally.

Q4: Why is China Mobile line latency generally higher than China Telecom and China Unicom when testing with a multi-region speed test tool?

The peering quality between ISP backbone networks and CDN edge nodes varies. Some CDN vendors deploy node clusters mainly in China Telecom and China Unicom data centers, so China Mobile users may need cross-network transmission, adding extra cross-network latency and packet loss. When evaluating a CDN, consider how evenly its nodes are distributed across the three major ISPs.