CDN for the ones who actually need it

The pitch for CDN is often a blanket recommendation: serve static assets from the edge, reduce latency everywhere. The reality is more precise. CDN improves performance when the content is static, cacheable, and requested from multiple geographic regions. For a regional SaaS product with authenticated users, you're mostly serving uncacheable responses — adding a CDN layer won't change your p95 latency by much, but it will add complexity to your cache invalidation story.

Before we integrate a CDN for any client, we ask three questions. Who is the audience and where are they? What percentage of traffic is actually cacheable? How frequently does content change, and what's the purge strategy when it does? If the answers are 'global', 'most of it', and 'we have a versioned deployment pipeline', then CDN is a meaningful investment. If the answers are 'one city', 'almost none of it', and 'we don't know', the conversation has to start somewhere else.

When CDN is the right tool, the implementation details matter more than the vendor. Cache-Control headers must be deliberate — max-age on immutable static assets, no-store on dynamic responses, stale-while-revalidate for content that can tolerate brief staleness. Every route needs an intentional caching policy, not the vendor default. An unconfigured CDN that caches user data or API responses can create security issues that are harder to debug than the performance gains are worth.

We've integrated CDN into projects where it shaved 250 ms off global median latency — the kind of change that moves conversion rates. We've also talked clients out of adding CDN to products where it would add cost and configuration overhead with no measurable benefit. The decision isn't technical snobbery; it's exactly the same analysis we apply to everything: does this solve the actual problem?