CDN for the ones who actually need it

A CDN — Content Delivery Network — is a system of servers spread across the globe. When a user opens your site, the files are sent not from one central server, but from the nearest node. This reduces the physical distance data has to travel, which means the page loads faster. Sounds simple, but in practice CDN is often recommended where it doesn't actually help.

CDN works well for static, unchanging files: images, fonts, JavaScript bundles, CSS. These can be cached on edge servers and delivered instantly. The problem is that most web apps serve a lot of dynamic content — pages that depend on the current user, their data, their permissions. A CDN can't cache that. It has to forward the request to the origin server anyway, and at that point you've added an extra hop without any benefit.

Before recommending CDN to a client, we always ask three questions: where are your users located, how much of your traffic is actually cacheable, and how often does your content change? If users are spread globally, most pages are static, and content changes rarely — CDN is a clear win. If users are all in one city and every page depends on authentication — CDN adds cost and complexity but moves the numbers by single-digit percentages.

The real gain from CDN isn't just speed — it's resilience. When traffic spikes, edge nodes absorb the load instead of hammering your origin server. We've seen CDN cut global median load times by 250ms on projects with international audiences. That's the kind of change that measurably moves conversion rates. But only when it's the right tool for the actual problem.