When a CDN helps—and what a quick test cannot tell you

The project draft describes turning a CDN off, then enabling it again a few days later. The useful lesson is not that either configuration always wins. It is how easily an incomplete test can support an overly confident conclusion.

Why the proxy was disabled

The page felt slow. An early test recorded 348–838 ms through the CDN against an internal response around 3 ms. But the test ran from the origin server, out through the CDN and back to itself. That is not the route a user takes.

A later test from a machine in Vietnam recorded:

This is not a complete controlled comparison. The routes tested different applications on the same server. TTFB includes their different processing work.

The TLS column is not conclusive either. We need to know whether it represents the TLS phase alone or a cumulative curl timestamp, whether connections were reused, and which protocols were negotiated. The table does not establish a fixed 70–80 ms CDN penalty.

An unfavorable route to the edge is one possible explanation, but identifying that requires routing evidence and the edge location code. Latency alone does not establish the location.

The team disabled the proxy at the time. These figures alone do not prove that was the better performance choice.

Why it was enabled again

The draft later records these ranges for the same page:

The ranges overlap in the samples recorded. An accompanying header was:

cf-cache-status: REVALIDATED

This means the cached resource was validated with the origin before being served. It does not prove there was no origin request or that the edge was in Vietnam. Headers, logs and controlled repeats are needed to explain the result.

A CDN may also provide DDoS mitigation and reduce direct origin exposure when DNS and firewall rules are configured correctly. It does not guarantee the origin IP has never been exposed.

The project account also describes the CDN accepting port 80 traffic while some direct international connections could not reach the origin. That is a separate operational observation, not proof of a universal CDN advantage.

Ask what can be cached

Origin distance and cache hit rate matter. For dynamic content, include routing, connection management and protection in the evaluation rather than assuming the proxy is only an added cost.

Three operational costs to plan for

1. Client IP handling changes

The origin sees connections from the proxy. A rate limiter can accidentally treat unrelated visitors as one client if it keys only on that address.

Trust forwarded client-IP headers only from authenticated, trusted proxies. Restrict origin traffic appropriately and configure the proxy chain. Accepting an IP header from arbitrary clients permits spoofing.

The draft also describes shared logs for a proxied and an unproxied application. An automatic ban based on those logs could block a CDN address range. Separate the logs and review the ban rules before enabling enforcement.

2. An old control file can delay an update

The draft reports an outdated service worker with a cache age of 6,411 seconds. The old worker silently discarded newly introduced notification kinds.

For stable worker URLs and runtime configuration, use an appropriate revalidation policy such as Cache-Control: no-cache. Check CDN overrides and the worker's installation and activation lifecycle too. no-cache permits storage but requires validation before reuse; no-store prohibits storage. Hashed application assets can still use long caching.

3. Origin certificates have a specific trust scope

Some CDNs supply origin certificates trusted by that CDN rather than ordinary browsers. Disabling the proxy can then expose a certificate browsers reject.

The project used a publicly trusted Let's Encrypt certificate at the origin to support both configurations. Check the trust scope of your own certificate before changing the route.

How to decide

1. Test the same content from real user locations, direct and proxied.

2. Record cache state, protocol and connection reuse.

3. Estimate how much traffic can safely use shared caching.

4. Include protection and operational requirements in the decision.

5. Repeat after deployment rather than relying on a provider's promise.

Figures are retained from the October 2026 Zukatek draft and were not independently verified. The first table compares different applications and must not be used as a CDN benchmark.

References: Cloudflare cache responses, MDN Cache-Control.