Setting Up a CDN for WordPress

A content delivery network is a set of servers in many locations, each holding copies of your files. When someone requests an image, they get it from the nearest location rather than from your origin server.

The benefits compound: lower latency for the visitor, less bandwidth and fewer requests hitting your server, and better resilience under traffic spikes. A modern CDN also gives you free TLS, HTTP/3, and usually a web application firewall and bot filtering as part of the package.

What it doesn't do is make your server faster. If the time to first byte on an uncached page is two seconds, a CDN doesn't change that for the first visitor to each page.

There's a meaningful difference between the easy version and the powerful one, and it's worth being deliberate about which you're doing.

Static asset offloading rewrites the URLs of your images, CSS and JavaScript to point at the CDN. Everything else still comes from your origin. It's low risk, easy to reverse, and delivers most of the bandwidth benefit.

Full-site proxying puts the CDN in front of everything by pointing your domain's DNS at it. Now the CDN sees every request and can cache HTML at the edge, filter bots and terminate TLS. Much more powerful, and the configuration matters much more — a mistake here serves wrong pages to real visitors.

Start with the first if you're unsure. Move to the second when you understand what needs excluding.

• Versioned assets — files with a content hash in the name — can be cached effectively forever. A change produces a new filename, so there's nothing stale to serve.
• Unversioned static files need a shorter life, or you'll be telling people to hard-refresh after every update.
• HTML, if you edge-cache it, needs a short life plus a purge on publish. This is where most of the risk lives.
• Never cache wp-admin, wp-login.php, the REST API's authenticated routes, or anything with a logged-in session.
• For a store, never cache cart, checkout or account pages. This is not optional — a cached cart will eventually show one customer another's basket.

Getting the exclusion list right is the whole job on a full-site setup. The rule is that anything varying per visitor must not be cached, and the ways a page varies aren't always obvious.

• Any URL under wp-admin, plus wp-login.php and the admin AJAX endpoint.
• Requests carrying a WordPress logged-in cookie, which should bypass the edge cache entirely.
• WooCommerce cart, checkout, account and order-received pages.
• Any page showing personalised content — a member area, a dashboard, a 'welcome back' message.
• Preview URLs, which carry a token and must never be cached.
• POST requests, always.

Every complaint that begins 'I updated the page and it still shows the old version' is a purge problem. Decide the strategy before you enable edge caching, not after the first complaint.

At minimum, publishing or updating a post should purge that URL, the archives it appears on, and the homepage if it's listed there. A product price change should purge the product page and the shop archive. Most caching plugins with CDN integration do this if configured; verify it rather than assuming.

Keep a manual purge-everything option available and know where it is. And be careful with very long HTML cache lifetimes on anything time-sensitive — a stock level cached for a day is worse than a slower page.

Most CDNs can transform images on request: resize, compress, and convert to WebP or AVIF based on what the browser accepts. This is genuinely valuable because it handles your existing library too, without regenerating anything or installing an optimisation plugin.

It also moves the work off your server entirely, which matters on shared hosting where image processing is expensive.

Check how the transformation interacts with WordPress's srcset. You want the browser choosing a size and the CDN serving an optimised version of that size — not the CDN overriding the choice with something larger.

• The real client IP. Behind a CDN every request appears to come from the CDN's servers unless you configure WordPress to read the forwarded header. Comment spam filters, login rate limiting and analytics all depend on this — a rate limiter seeing one IP will eventually lock out everybody at once.
• Mixed content warnings, if the CDN serves over HTTPS and something in your content links to HTTP.
• CORS on fonts, which need the right headers to load cross-origin. A missing font is the classic first symptom of asset offloading.
• Preview and draft URLs getting cached and shown to the public.
• Redirect loops when both the CDN and the origin try to force HTTPS or a canonical hostname. Decide which one is responsible.
• Double compression or double minification when the CDN and a plugin both do it.

• Check the response headers for a cache status — most CDNs report HIT, MISS or BYPASS. A page that always says MISS isn't being cached.
• Test from several locations, not just your own, using an external testing tool.
• Log in and confirm you're bypassing the cache, then check in a private window that anonymous visitors get the cached version.
• For a store, add something to the cart in one private window and check the cart in another. It must be empty.
• Publish a change and confirm it appears within seconds, which proves the purge works.
• Check that wp-admin is never cached by looking at the headers while logged in.

If your audience is entirely in one city and your server is in that city, the latency benefit is small. You still get the TLS, the HTTP/3, the bot filtering and the origin protection, and free tiers cover a lot of small sites.

If any meaningful share of your visitors is far from your server — an Indian business with overseas customers, or the reverse — it's one of the largest single improvements available, and usually larger than anything you'd achieve by tuning the server.