CDNsun and other CDNs sit between your users and your origin to reduce latency, increase throughput, and protect infrastructure from traffic spikes. But the real gains (or disappointments) come down to how a single request is routed, negotiated over TLS, evaluated for caching, and fetched from origin on a miss. This article walks through that end-to-end request path and the decisions that most affect performance and cache hit ratio.
From URL to edge: DNS routing, connection reuse, and the TLS latency tax
A CDN request effectively starts before the first byte of HTTP is sent. Two stages dominate early latency: how the client is routed to an edge and how quickly it can establish an encrypted connection.
DNS decides which edge you even talk to. When a browser resolves a hostname like cdn.example.com, DNS returns an IP owned by the CDN. That sounds simple, but the “closest edge” is a best-effort approximation influenced by network reality.
- Anycast: multiple edge locations advertise the same IP prefix; Internet routing (BGP) typically sends the client to a “nearby” POP, but “nearby” can mean lowest routing cost, not lowest latency.
- Geo DNS: DNS answers vary by the resolver’s location. This is often accurate for enterprise resolvers, but can be misleading when users rely on resolvers far from them (corporate VPNs, public resolvers, ISP architectures).
- What really influences routing: ISP peering, congestion, local outages, and where the DNS resolver sits relative to the end user.
What you can usually control is the DNS shape of your assets: use a dedicated hostname for cacheable content (for example, cdn.example.com) and keep DNS TTLs reasonable so you can adjust routing, providers, or configurations without waiting days for caches to expire.
Connection setup and TLS can dominate “time to first byte”. After DNS, the client opens a connection and negotiates TLS. On a warm connection, this cost is near zero. On a cold connection, it can be the slowest part of the request, especially on mobile and high-latency networks.
- Why it’s slow: first-time TLS handshakes require multiple round-trips; packet loss magnifies the delay; misconfigurations can force fallback or extra negotiation steps.
- Why it’s fast when done right: keep-alive allows many requests over one connection; TLS session resumption reduces repeated handshake cost; HTTP/2 multiplexing avoids opening many parallel connections; HTTP/3 (when available) can reduce head-of-line blocking and speed up handshake behavior on lossy networks.
Practical takeaway: if users report “good bandwidth but slow page loads,” inspect connection reuse, TLS resumption rates, and protocol negotiation. A CDN can be geographically close and still feel slow if each asset pays the full handshake penalty.
At the edge: cache keys, HIT vs MISS, and why small differences kill performance
Once the edge receives your HTTP request, it makes a deceptively simple decision: can it serve the exact response from cache, or must it fetch from origin? Everything depends on how the edge builds the cache key, which defines what makes two requests “the same.” A high hit ratio is rarely about “turning on caching” and more about making the cache key stable and intentional.
What typically belongs in a cache key
- Path: almost always included (/assets/app.3f2c1.js).
- Query string: sometimes included, sometimes normalized. Including it blindly is a common mistake.
- Selected headers: included only when they legitimately change the representation (for example, some language or device variations).
- Cookies: almost never for static assets; cookies fragment cache and frequently force bypass.
Common ways teams accidentally destroy caching
- Tracking parameters: allowing every utm_*, gclid, fbclid parameter into the cache key creates a new cache object per campaign click. Normalizing or ignoring known tracking parameters is one of the highest-impact fixes.
- Overusing Vary: a broad Vary header multiplies cache entries. For example, Vary: User-Agent can explode cache size and reduce hit ratio dramatically, especially if bots or many device variants exist.
- Sending cookies to the asset hostname: even if your origin ignores them, the presence of cookies can cause caching rules to bypass, or it can make the cache key unique per user.
- Unnecessary content negotiation: letting minor headers alter the representation (or appear to) prevents reuse. Decide what truly needs to vary and strip the rest at the edge.
What you get on a cache HIT: when the edge has a fresh cached response for that cache key, it returns it immediately.
- Latency drops: fewer hops and no origin round-trip.
- Throughput increases: edge networks are tuned for delivery, often with better peering and optimized congestion behavior.
- Origin load disappears: the request never touches your infrastructure.
Performance gains on hits are amplified when the CDN also handles compression correctly (Brotli/gzip for text assets), preserves content-type accuracy, and serves over efficient protocols like HTTP/2. For modern frontends with many small assets, multiplexing alone can meaningfully improve page load stability.
What happens on a cache MISS: the edge becomes a client to your origin and performs an origin fetch. This is where CDN configuration and origin behavior intersect, and where cost and reliability risks show up.
- Connection reuse to origin: keeping a pool of warm connections avoids repeated handshakes and reduces origin CPU overhead.
- Request coalescing: if many users request the same uncached object at once, a good CDN avoids sending identical concurrent fetches to origin (reducing “thundering herd” effects).
- Concurrency limits and shielding: limiting spikes protects the origin during flash crowds; shielding (tiered caching) can force misses to go through a regional layer before origin, smoothing load.
Frequent misses usually come from mismatched caching policy rather than lack of demand: TTLs too short for stable assets, fragmented keys from query strings/cookies, overly aggressive purges, or content that is uncacheable by design (personalized HTML or truly per-user API responses).
What gets stored (and for how long): Cache-Control, TTL strategy, and purges that do not backfire
After an origin fetch, the edge decides whether it is allowed to store the response and how long it remains valid. While CDNs offer overrides, the safest and most portable approach is to make your origin’s caching intent explicit with the right headers, then use CDN rules to refine edge behavior where necessary.
The headers that actually control cacheability
- Cache-Control: the primary source of truth.
- max-age: browser TTL (client-side caching).
- s-maxage: shared cache TTL (CDN/proxies), often more important than max-age for CDNs.
- public vs private: whether shared caches may store the response.
- no-store: do not store anywhere (use sparingly, but essential for sensitive responses).
- Expires: legacy TTL; still encountered, but generally superseded by Cache-Control.
- Vary: indicates which request headers create distinct representations; powerful, but easy to misuse.
Practical TTL patterns that scale
- Immutable, versioned assets (for example, app.3f2c1.js, styles.91ac.css): long TTL at both browser and CDN, because the filename is the cache-buster. This maximizes hit ratio, minimizes origin load, and reduces repeat visits’ load time.
- HTML: often a short TTL, or a strategy using stale-while-revalidate where acceptable. This gives fast responses while still letting you refresh content in the background.
- APIs: cache only when responses are truly shared, safe, and stable (for example, public catalog data). Avoid caching personalized or authorization-dependent responses unless you have strict controls and a correct cache key that includes the right identity boundaries.
Purges and updates: why you still see old content. If you deploy new content at the same URL, cached objects will keep serving until TTL expiry unless you invalidate them. There are three reliable strategies, each with trade-offs.
- Cache-busting filenames: best for static assets. New deployment means new URLs, so no purge is required and old versions can expire naturally.
- Purge by URL or prefix: useful for urgent fixes, but operationally expensive if overused. Frequent purges reduce cache efficiency and can cause origin load spikes right after invalidation.
- Short TTLs: simplest to reason about, but increases misses and origin traffic. Good for content that legitimately changes often, not for assets that do not.
The strongest production setup typically combines long-lived versioned assets, controlled HTML caching (possibly with revalidation), and careful use of purges as an exception rather than the default deployment mechanism.
In practice, CDN performance is determined less by “having a CDN” and more by routing accuracy, TLS and connection reuse, and a cache key that avoids accidental fragmentation. Hits are where you get the real wins: low latency, high throughput, and minimal origin load. Miss handling and TTL strategy decide whether your origin stays stable under spikes and deployments. Configure caching intentionally, purge sparingly, and let CDNsun do what an edge network does best: serve the right bytes fast, close to users, at scale.