CDN Testing: Validating Cache, Performance, and Failover

CDN misconfigurations are uniquely dangerous because they affect every user simultaneously. A broken cache rule can serve stale content to millions. A misconfigured WAF rule can block legitimate traffic. An untested failover can leave your site unreachable when the origin goes down. Yet many organizations deploy CDN changes directly to production with no testing—an approach that would be unthinkable for application code. For a comprehensive overview, see our guide on CDN Monitoring and Observability: Metrics That Matter — FlyFish NWA.

This guide establishes a systematic CDN testing practice: cache behavior verification, performance benchmarking, failover validation, and a comprehensive pre-deployment checklist. These techniques catch configuration errors before they reach users and provide confidence that your CDN performs as designed.

How Do You Test CDN Cache Behavior?

Cache behavior testing verifies that the CDN caches what it should, does not cache what it should not, and expires content at the correct time. This is the most fundamental CDN test and the one most often skipped.

The curl test pattern. The simplest and most reliable cache test uses curl with header inspection. Send two sequential requests to the same URL and examine the cache status header:

First request (cache MISS expected):

curl -sI https://example.com/style.css

Look for: CF-Cache-Status: MISS (Cloudflare), X-Cache: Miss from cloudfront (CloudFront), or X-Cache: MISS (generic).

Second request (cache HIT expected):

curl -sI https://example.com/style.css

Look for: CF-Cache-Status: HIT, X-Cache: Hit from cloudfront, or X-Cache: HIT. Also verify the Age header is greater than 0.

Cache exclusion testing. Verify that pages that must not be cached are indeed excluded: login pages, checkout pages, user dashboards, and API endpoints with authentication. Send requests with authentication cookies and verify the response is DYNAMIC or BYPASS, not HIT.

Vary header testing. If your CDN varies cache by Accept-Encoding, User-Agent, or custom headers, verify that different header values produce separate cache entries. Send requests with Accept-Encoding: gzip and Accept-Encoding: br and confirm both receive correct content.

TTL verification. To verify TTL behavior, request a resource, wait for the TTL to expire, then request again. The second request should show a MISS or EXPIRED status. For long TTLs, check the max-age value in the Cache-Control header and the Age header to calculate remaining cache lifetime. For deeper cache mechanics, see CDN Caching Strategies.

What Tools Are Best for CDN Performance Testing?

CDN performance testing measures the actual speed improvement the CDN delivers. Use a combination of synthetic and load testing tools.

WebPageTest for CDN analysis. Run tests from multiple locations (US East, EU West, APAC) with both first view (cold cache for the browser, likely warm cache at CDN) and repeat view (warm browser cache). Compare TTFB across locations—it should be consistently low (under 100 ms for cached content) regardless of distance from origin. The waterfall chart reveals which resources are served from CDN (fast TTFB) versus origin (slow TTFB).

Load testing through CDN. Use k6 or Locust to simulate concurrent users hitting the CDN. Key metrics: requests per second (the CDN should handle your peak traffic), p99 latency (should remain under 200 ms), error rate under load (should remain below 0.1%), and origin hit rate (should not increase proportionally with load if caching is effective). See Core Web Vitals for the performance targets to test against.

Comparative testing. When evaluating CDN providers or configuration changes, run identical tests against the current and proposed configurations. Use a side-by-side comparison: same URLs, same test locations, same time of day. This eliminates variables and provides a clean comparison of CDN performance impact.

How Do You Test CDN Failover?

Failover testing verifies that your CDN handles origin failures, PoP failures, and provider failures gracefully. This is the test most organizations skip—and the one that matters most during an actual outage.

Origin failure simulation. Test what happens when the CDN cannot reach your origin: block CDN origin-fetch IPs on your origin firewall, or shut down the origin server in a staging environment. Verify: the CDN serves stale cached content (if you have configured stale-if-error), the CDN returns your custom error page (not a generic CDN error), and monitoring alerts fire within the expected timeframe.

Origin slow response simulation. Introduce artificial latency at the origin (200 ms, 500 ms, 2 seconds, 5 seconds). Verify: the CDN's timeout settings trigger at the configured threshold, stale-while-revalidate serves cached content while waiting for origin, and the CDN does not cascade the slowness to all users.

Multi-CDN failover. If you use multiple CDN providers for redundancy, simulate a complete CDN provider failure: change DNS to remove the primary provider and verify that traffic flows to the secondary provider. Measure: failover time (DNS propagation), cache warmth on the secondary provider (did you pre-warm?), and whether all features work on the secondary (WAF rules, edge functions, SSL).

Chaos testing. Schedule regular failover drills (monthly or quarterly). The first drill always reveals configuration gaps: stale content that has expired since the last cache warm, SSL certificates that were not renewed on the backup CDN, or edge functions that were not deployed to the secondary provider.

How Should You Set Up a CDN Staging Environment?

A staging CDN environment mirrors production configuration on a non-production domain. Every CDN change should be tested in staging before production deployment.

Staging architecture. Create a separate CDN zone or distribution for your staging domain (staging.example.com). This zone should have: the same cache rules as production, the same WAF and security rules, the same edge functions, and an origin pointing to your staging application server.

Configuration synchronization. Use infrastructure as code to ensure staging and production CDN configurations stay in sync. Share the same Terraform modules with environment-specific variables. When you change a cache rule in the staging module and it passes testing, the same change applies to the production module via PR merge.

Testing in staging. Before every production deployment, validate in staging: new cache rules (cache and exclusion behavior), WAF rule changes (no false positives on legitimate traffic), edge function updates (correct request handling), SSL certificate changes (no certificate errors), and redirect rule modifications (correct target URLs).

How Do You Test CDN Edge Functions?

Edge functions (Cloudflare Workers, CloudFront Functions, Fastly Compute) require testing at multiple levels because they execute on every matching request.

Unit testing. Test function logic in isolation using local test frameworks. Mock the request and response objects, invoke the function, and assert the output. This catches logic errors without deploying to the CDN. Cloudflare's Miniflare and Wrangler dev mode provide local Worker execution environments.

Integration testing. Deploy the function to the staging CDN and send test requests. Verify: correct request routing, correct response headers, correct body transformation, and correct error handling. Use automated test suites that run against the staging CDN endpoint after every function deployment.

Canary deployment. For production deployment, use the CDN's traffic splitting capability to route 5–10% of production traffic through the new function version. Monitor error rates and latency. If metrics are healthy after 1–2 hours, increase to 100%. This approach is detailed in the CDN Architecture Patterns guide.

What Does a CDN Testing Checklist Look Like?

Use this checklist before every CDN configuration change reaches production. Each item should be verified in the staging environment first.

Cache behavior:

• Static assets return cache HIT on second request
• Dynamic/authenticated pages return BYPASS or DYNAMIC
• Cache-Control headers match configured TTLs
• Vary headers are correct (not over-broad)
• Query parameter handling matches expectations
• Cache purge works (content updates after purge)

Security:

• WAF blocks known attack patterns (SQLi, XSS test payloads)
• WAF does not block legitimate traffic (test with real user agents)
• Rate limiting triggers at configured thresholds
• SSL/TLS is enforced (HTTP redirects to HTTPS)
• HSTS header is present with correct max-age
• Security headers present (CSP, X-Frame-Options, etc.)

Performance:

• TTFB under 100 ms for cached content from key regions
• Compression enabled (Brotli preferred, gzip fallback)
• HTTP/2 or HTTP/3 negotiation working
• Image optimization producing correct formats

Reliability:

• Custom error pages display on origin failure
• Stale content served during origin downtime (if configured)
• Health checks detect origin degradation
• DNS failover routes to backup (if multi-CDN)

Functionality:

• Redirects resolve to correct destinations
• Edge functions execute correctly
• Custom domains resolve with valid SSL
• API endpoints accessible with correct CORS headers

For diagnosing issues found during testing, the CDN Troubleshooting Guide provides systematic debugging approaches. For ongoing performance validation, integrate Real User Monitoring alongside synthetic tests.