A content delivery network sits between your visitors and your server. It keeps copies of your files in many locations, answers most requests itself, and only comes back to your server for what it does not have. For static files it is excellent. For a global audience it is often the single biggest speed gain available, and for a small site under pressure it can be the difference between a quiet day and an outage.
It is also an extra system between you and your visitors, with its own caching rules, its own idea of encryption and its own place to look when something goes wrong. Most CDN problems are not faults in the CDN. They come from the gap between what the CDN assumes about your site and what your site actually does.
This piece covers what a CDN does mechanically, where it earns its keep, the three problems that account for most support tickets (personal pages cached, encryption mode mismatches, stale content), and how to decide if you need one. It is written for site owners rather than network engineers, so the vocabulary is kept to what you will see in a dashboard.
What a CDN does on each request
When you put a CDN in front of a site, your domain's DNS is changed so visitors reach the CDN's servers instead of yours. Those servers, called edges or points of presence, are spread across many cities. The visitor is directed to a nearby one.
The edge checks whether it holds a fresh copy of the requested URL. If it does, that is a cache hit, and the answer goes back immediately without troubling your server. If not, it is a miss: the edge requests the file from your server (the origin), passes it to the visitor, and keeps a copy for the next person.
That is the whole idea. Everything else in this article is a consequence of the edge holding a copy on your behalf, and of that copy being served to people you did not individually vet.
Where it shines
Images, stylesheets, scripts and downloads. These are identical for every visitor, rarely change, and make up most of the bytes on a typical page. A CDN turns each of them into a short trip rather than a long one, and takes the repeated load off your server.
Traffic spikes, since the network absorbs the load. If a post gets shared widely, the edge serves the cached copy thousands of times while your server answers once per edge location. A small plan that would fall over under that load stays upright.
Hostile traffic, since most CDNs filter floods and obvious attacks before they reach you. Basic denial-of-service traffic, abusive bots and many automated exploit attempts stop at the edge. This does not replace keeping software updated, but it removes a lot of noise.
A site whose server is on one continent and whose readers are on another. Distance costs time in a way no amount of server tuning can fix: a round trip between continents takes on the order of a hundred milliseconds or more, and a page load needs several of them. The edge cuts the number of long trips, and modern CDNs also keep a warm, reused connection to the origin, which helps even uncached requests.
Where it causes trouble
Personal pages cached for everyone
Caching pages that should be personal is the nightmare. If a shopping cart, a logged-in dashboard or a page with a user's name gets stored and served to the next visitor, you have a privacy incident. It has happened to large sites and tiny ones, and the usual cause is a "cache everything" rule applied before anyone thought about the exceptions.
Good setups exclude anything with a login or cart cookie from caching, along with checkout, account and admin paths, and anything that responds with Cache-Control: private or no-store. You should test that rather than assume. Log in on one browser, load an account page, then open the same URL in a private window and confirm you are not seeing the first session's data.
Encryption mode and redirect loops
The second classic problem is encryption mode. A CDN has two connections to manage: visitor to edge, and edge to origin. Dashboards usually let you choose how the second one behaves. If the CDN talks to your server over plain HTTP while your server forces HTTPS, you get a redirect loop: the edge asks for the page on port 80, the origin replies "go to HTTPS", the edge follows it back to the visitor, the browser asks again, and round it goes until the browser gives up with "too many redirects".
The fix is a valid certificate on your server and the CDN set to verify it. Many dashboards offer a weaker middle option, where the edge uses HTTPS to the origin but does not check the certificate. It stops the loop, but leaves the second connection open to impersonation, so treat it as a stopgap. A free automatically renewed certificate on the origin costs nothing, and the ACME explainer shows how that renewal works. Remember that the origin certificate also expires; the SSL expiry tool checks what a server presents, though you may need to test the origin address directly rather than through the CDN.
Stale content
Third, stale content. You publish a change and some visitors keep seeing the old page until the CDN's copy expires. Know how to purge, and set reasonable expiry times: long for files with versioned names, short for HTML. Purging a single URL is quick and cheap; purging everything is a blunt tool that sends a wave of misses to your origin.
Some CDNs offer "serve stale while revalidating", where an expired copy is given out immediately while a fresh one is fetched in the background. It hides origin slowness well, but it also means a change can take one extra visit to show. Decide knowingly if you want it.
Smaller problems worth knowing
The visitor's address in your logs becomes the edge's address, unless your server is configured to read the forwarding header the CDN adds. That breaks IP-based rules, rate limits, geolocation and security plugins, which then see a few CDN addresses rather than thousands of visitors. Configure the real-IP setting on the server, trusting the header only from the CDN's published ranges. Our piece on reading access logs explains why this matters when you investigate an incident.
Firewalls can work against you the other way. If your server only accepts traffic from the CDN's address ranges, visitors cannot bypass the filtering, which is useful; but a script, a monitoring service or a cron job that calls your own domain from the same server may now travel out and back in through the CDN. Keep a way to reach the origin for tools that need it.
Cookies and query strings interact with caching in ways that surprise people. If every URL has a unique tracking parameter, each is a different cache entry and hit rates fall. If the CDN ignores query strings, ?page=2 may return page one. Check how yours treats them.
Finally, there is dependence. A CDN outage, a billing lapse or a misconfigured rule takes your site with it. Know how to point DNS back at your origin quickly; a low TTL on the relevant records makes that possible, and the TTL planner can help you pick values.
Do you need one?
If your audience is local and your server is nearby, the gain is smaller, though the security filtering can still be worth having. A bakery in one town with a server in the same country will see little change in load times, but may like the attack filtering and the automatic HTTPS handling.
If you are on a small shared plan and a CDN lets you serve images from elsewhere, it can lower your resource use noticeably, because image requests are the bulk of the hits. Plans with tight limits on CPU or concurrent connections tend to feel this first.
If your site is mostly logged-in, personalised or real-time, such as a members area or a booking system, a CDN helps with static assets but little with the pages themselves, and the cost of getting caching rules wrong is high. Consider caching only the asset paths.
Try it on a staging copy first and check every feature that involves logging in: login itself, password reset, cart, checkout, form submissions, and admin pages. Then roll out with HTML caching off, and add page caching later once you have seen the headers behave.
Quick answers
Will a CDN make my WordPress site fast by itself?
It will speed up images, styles and scripts. A slow dashboard, slow database queries or a heavy theme remain slow, and uncached HTML still waits for your server. Pair the CDN with a page cache on the origin.
Does a CDN replace a backup or a firewall?
No. The edge may hold copies of your files, but it is not a backup, and it can only filter what passes through it. Anyone who learns your origin address can still reach the server directly unless you restrict it.
Why do I see my old site for some people after changing hosts?
If DNS or a CDN origin setting still points at the old server, visitors are served from there, and cached copies may linger as well. Check the origin setting first, then purge.
Is it a problem to use a CDN with email on the same domain?
Only the website records should go through the CDN. Mail records, such as MX and the host name that mail connects to, must point at the real mail server directly. A proxied record on a mail host name is a common reason mail stops arriving.