A CDN keeps copies of your files on servers around the world and serves each visitor from a nearby one. It reduces distance, takes load off your server, and absorbs traffic that would otherwise reach you.
It is also frequently added to sites that do not need it, where it introduces a caching layer and solves nothing.
When it genuinely helps
Your audience is geographically spread. A visitor on another continent pays the round-trip time on every request, and on a page making forty requests that compounds into something they notice.
You serve large files. Images, downloads, video. This is where the transfer savings are real.
You get traffic spikes. A CDN absorbs the surge, so a busy day does not reach your server at all.
You want the security layer. Most CDNs include DDoS absorption and a web application firewall, and that is often the actual reason people adopt one.
When it does not
A local business whose visitors are all in one city. The distance a CDN saves is already zero.
A site that is slow because it has no caching, or because its images are four megabytes each. A CDN delivers those images faster from somewhere closer. They are still four megabytes, and optimizing images is the fix that actually applies.
A site whose pages are slow to generate. The CDN caches what your server produces; it does not make producing it faster. Caching layers deals with which layer your problem is in.
Two ways to connect one
Full proxy. You point your domain's nameservers at the CDN, and all traffic passes through it. This is how the security features work, because the CDN sees every request. It also means your DNS is managed there.
Asset-only. You keep your DNS where it is and serve static files from a CDN hostname. Less invasive, no security benefit for the site itself, and it requires your site to rewrite asset URLs.
Full proxy is the usual choice and the bigger commitment. Asset-only suits a site that only wants faster images.
Setting it up
For a full proxy: create the account, let it import your existing DNS records, verify every one of them came across, then change nameservers at your registrar.
That verification step is the one to take seriously. An import that misses your MX records means mail stops the moment the nameservers change, and the connection between those two events is not obvious when the website is plainly working. For what to check, see understanding MX records.
Keep a copy of your current DNS records before starting. It turns a problem into a paste.
Mail must not go through the CDN
Worth stating separately because it is the classic mistake.
Records used for mail (and any hostname your mail server uses) must be set to bypass the proxy. A CDN proxies web traffic; mail sent to a proxied address does not arrive.
In most interfaces this is a toggle per record. Check it on the mail records specifically, because the default is usually to proxy everything.
Certificates, and the mode that matters
A full-proxy CDN terminates HTTPS at its edge and connects to your server separately. How it makes that second connection is a setting, and the wrong value is a real weakness.
Full (strict). The CDN verifies your server's certificate. This is the correct setting.
Full: encrypted but the certificate is not verified.
Flexible: the CDN connects to your server over plain HTTP. Visitors see a padlock while the traffic between the CDN and your server is unencrypted, which is worse than it looks because it appears secure.
Install a valid certificate on your server and use Full (strict). Flexible also causes redirect loops when your server redirects to HTTPS, because your server sees an HTTP request every time. Forcing HTTPS goes into that interaction.
Your logs stop showing visitors
Once traffic passes through a proxy, every request arrives from the CDN's addresses. Your access log shows those instead of your visitors.
The visitor's real address is in a header, and the server has to be configured to use it. Until then, several things break quietly: rate limiting by address limits the CDN, country-based rules see the wrong country, and anything that blocks abusive addresses blocks the proxy.
Configure the real-IP handling at the same time as the CDN, not later. Viewing website statistics explains where the log lives.
Another cache to clear
A CDN is one more place a stale version hides, and it is the one furthest from you.
Purge it when you change a template, a stylesheet or an image. Publishing a post usually triggers a purge; editing a theme file usually does not.
During development, most CDNs have a temporary bypass mode. Use it rather than purging after every change, and remember to turn it off. A site left in bypass gets no benefit at all and nobody notices, because everything works.
What to cache and what never to
Static assets, images, CSS, JavaScript, fonts, cache aggressively and safely.
HTML is the decision. Caching it is the largest gain available and it requires the same exclusions as any page cache: never cart, checkout, account pages, or anything showing information specific to one person.
Caching a logged-in page at the edge can serve one visitor's page to another. At CDN scale that is a serious incident instead of an inconvenience. For the shop exclusions, see WooCommerce speed optimization.
Check it is actually doing something
Response headers tell you whether a request was served from the edge or passed through to your server.
curl -I https://example.com/style.css
Look for a cache-status header reporting a hit. A site behind a CDN where everything reports a miss is paying the extra hop for no benefit, usually because the origin sends headers telling the CDN not to cache.
Test from more than one location, and confirm your own IP handling works by looking at a fresh log entry after visiting the site.
Whether a CDN will help is a measurable question instead of a general one. How to Measure Page Speed Properly goes into taking the measurement first.