A CDN keeps copies of your site at data centers around the world and serves each visitor from the nearest one. The pitch is simple and mostly true. What gets left out is that the size of the benefit varies enormously depending on who visits you and how your site is built, and that a badly configured CDN can make things slower or actively break checkout.
Advertisement. We earn a commission if you sign up through this link, at no extra cost to you.
So: what it does, when it is worth it, when it is not, and how to set one up without causing the classic problems.
The physical problem
Data moves at roughly two-thirds the speed of light through fiber, and it does not travel in a straight line. A request from Singapore to a server in Frankfurt covers something like 10,000 kilometers each way, through a series of intermediate hops.
That is around 150 to 200 milliseconds for one round trip — and a first connection needs several. DNS, TCP handshake, TLS negotiation, then finally the request. Half a second can disappear before your server has done any work at all.
You cannot compress your way out of this or optimize the server. Distance is distance. The only fix is to answer from somewhere closer, which is what a CDN is.
When a CDN clearly earns its place
Your audience is spread across continents. This is the core case. If Search Console shows meaningful traffic from several regions, visitors far from your server are having a materially worse experience than the one you test locally.
You serve a lot of static weight. Images, video, fonts, downloads. These cache perfectly at the edge and are usually most of your bytes.
You get traffic spikes. Cached content served from the edge never touches your origin, which is the difference between a busy day and an outage.
You want protection at the front door. Modern CDNs bring DDoS mitigation, a WAF and bot filtering. For many sites this justifies it independently of speed.
When it does not do much
Worth saying plainly, because “get a CDN” is offered as universal advice and it is not.
A single-country audience with local hosting. If everyone who visits is within a few hundred kilometers of the server, there is little latency to remove. You may add a hop rather than remove one.
A site that is already fast and light. If TTFB is 200 milliseconds and the page is under a megabyte, a CDN has little to work with.
Mostly dynamic, personalized content. Logged-in dashboards and carts cannot be cached at the edge in any simple way. You can still terminate TLS closer to the user, which helps, but it is a fraction of the benefit.
As a substitute for fixing the site. A CDN delivers your unoptimized 5 MB images faster. It does not make them smaller. Solve the site first; a CDN multiplies whatever you give it, in both directions.
Finding out whether you have a problem
Do not guess at this.
Test from where your visitors are. WebPageTest lets you choose the test location. Run your homepage from your own city, then from the two regions Search Console says send you the most traffic. The gap between those numbers is the size of the problem.
Look at the geographic split first. Search Console’s Countries report and GA4’s location data. A site whose traffic is 90 percent domestic has a different answer from one split across three continents.
Compare TTFB by region. If TTFB is 200 milliseconds locally and 900 from a region that sends real traffic, that 700 millisecond difference is pure distance, and it is exactly what a CDN removes.
Choosing one
Cloudflare — the default answer for most sites. The free tier is genuinely useful, the network is large, and it bundles security. It works as a full proxy, which means changing your nameservers.
Bunny — inexpensive, fast, simple, pay-as-you-go. A good choice when you want a CDN and not a platform.
Fastly and Akamai — enterprise-grade, highly configurable, priced accordingly.
Your host’s built-in CDN. Many managed WordPress hosts include one. Usually the least work and often sufficient — check what you already pay for before adding another layer.
The distinction that actually matters is not the brand but the mode: static assets only, where the CDN serves images, CSS and JavaScript while HTML comes from your origin, versus full-page caching at the edge, where the HTML is cached too. The second is far faster and far easier to get wrong.
Configuring it without breaking things
Nearly all CDN problems come from the same handful of mistakes.
Never cache pages for logged-in users. The failure mode here is serving one user’s session-specific page to another. Every WordPress CDN integration has a rule that bypasses cache when a WordPress login cookie is present. Confirm it is on.
Exclude cart, checkout and account pages entirely. No exceptions, no clever partial caching. A cached checkout page is worse than a slow one.
Set cache lifetimes deliberately. Static assets with a hash in the filename can be cached for a year, because a change produces a new filename. HTML should be short — minutes — or purged on publish. Getting this backwards produces a site that either never updates or never caches.
Cache-Control: public, max-age=31536000, immutable # hashed assets
Cache-Control: public, max-age=0, s-maxage=300 # HTMLPurge on publish. Every serious WordPress CDN plugin will clear the relevant cache when you update a post. If yours does not, you will publish a correction and watch the old version stay live for hours.
Do not stack caches carelessly. A page cache plugin, a host-level cache and a CDN cache all holding the same HTML means three places to purge and three ways to serve something stale. Pick where full-page caching happens and let the others handle their own layer.
Check for mixed content and hotlink rules. Assets that were loading over HTTP, or hotlink protection that does not know about the CDN hostname, both produce silently missing images.
Edge compute, briefly
The newer capability is running code at the edge rather than only storing files there — Cloudflare Workers, Fastly Compute, the edge functions offered by the deployment platforms.
This is genuinely useful for redirects, A/B splits, header manipulation, geographic routing and personalization that would otherwise force a trip to the origin. It is also a real engineering commitment, with its own runtime, deployment process and debugging story.
For a WordPress site whose main problem is that images are too big and the server is slow, edge compute is not the answer to that question. Worth knowing it exists; not worth reaching for until the ordinary layers are in place.
Verifying it works
After setup, check three things rather than assuming.
Cache hit ratio. Every CDN dashboard reports it. Below 80 percent on static assets means something is preventing caching — usually a cookie or a query string in the URL.
The response headers. Look for cf-cache-status: HIT or the equivalent. A MISS on every request means the CDN is a proxy adding a hop and caching nothing.
The same regional tests as before. Same tool, same pages, same locations. If the distant-region numbers have not moved, the CDN is not doing the thing you installed it for.
The short version
A CDN removes distance, and only distance. If your visitors are far away or numerous, it is one of the largest single improvements available. If they are all nearby and your site is already light, it is a hop you did not need. Either way it is a multiplier on what you serve, so fix the images and the server first — then check your cache hit ratio, keep logged-in and checkout pages out of the cache, and test from where your visitors actually are.
Working through this list on your own site and would rather not? That is what an Expert Web Audit is for.
Advertisement. We earn a commission if you sign up through this link, at no extra cost to you.
