What is a CDN, and how content delivery networks work
Quick answer
A CDN, content delivery network, is a set of caching servers spread across many locations that serve a copy of your content from whichever location is closest to the visitor, instead of every visitor fetching it from your one origin server. That cuts load time for the visitor and cuts the load your origin server has to handle.
Origin vs. edge
Your origin is the server that actually holds the real, authoritative copy of your content, the one you upload to and update. A CDN puts a layer of edge servers, also called edge nodes or points of presence, in front of that origin, spread across many geographic locations. When a visitor requests something, the request goes to the nearest edge node rather than all the way to the origin. If that edge node already has a cached copy, it serves it directly. If it doesn't, it fetches the content from the origin once, serves it, and caches it for the next visitor in that region.
The effect is twofold. Visitors get content from a server that's physically closer to them, which usually means less network latency and a faster load. And the origin server only has to serve each piece of content occasionally, to refresh edge caches, rather than for every single visitor request, which reduces the load and bandwidth it needs to handle directly.
What's actually cacheable
Not everything benefits equally from a CDN. Static assets, images, CSS, JavaScript, video, downloadable files, are the clearest fit: the same bytes go out to every visitor, so caching them at the edge is straightforward and the cache stays valid until the file itself changes.
Dynamic or personalised content is a different story. A page that's different for every visitor, showing their account details or a personalised feed, generally isn't safe to cache as-is, since caching it would risk serving one visitor's private content to another. It's not that dynamic content can never sit behind a CDN, but it needs deliberate cache rules, caching by user or session, short expiry windows, or excluding certain paths entirely, rather than the default cache-everything behaviour that works fine for static assets.
Cache invalidation and purging
Cached content doesn't stay accurate forever if the origin changes. Every cached copy has an expiry, set by how long the CDN is told to keep it, and once that expiry passes the edge node fetches a fresh copy from the origin the next time it's requested. That works fine when a delay of minutes or hours between updating the origin and visitors seeing the update is acceptable.
When it isn't, purging (also called cache invalidation) is the alternative: an explicit instruction telling the CDN to drop a specific cached copy immediately, rather than waiting for it to expire naturally. This matters most for content that changes on a schedule you don't control in advance, publishing an update and needing it visible right away, rather than whenever the old cached copy happens to expire.