A content delivery network is the single most reliable speed upgrade you can bolt onto a WordPress site without rewriting a line of code. But "set up a CDN" hides a fork in the road that almost every quick tutorial skips, and choosing the wrong branch is why so many sites end up with a CDN that does nothing — or worse, one that serves a logged-in user's shopping cart to a stranger. This guide is about getting that decision right, then wiring the rest correctly.

The one architectural choice that defines your setup

Every WordPress CDN configuration is one of two shapes. Understand which one you're building before you touch a dashboard.

Option A: Full-site reverse proxy (DNS-level)

Here the CDN sits in front of everything. You point your domain's nameservers (or a proxied DNS record) at the provider, and every request — HTML, CSS, images, even POSTs to the cart — flows through the edge. This is the Cloudflare "orange cloud" model, and it's also how host-integrated CDNs like Cloudflare Enterprise on Rocket.net or WP Engine work. The edge can cache full HTML pages, terminate TLS, run HTTP/3, and apply a WAF. The catch: because it touches dynamic requests too, you have to be deliberate about what gets cached.

Option B: Static-asset offload (CNAME pull zone)

Here your origin still serves the HTML directly, and only static files — images, fonts, JS, CSS — are rewritten to a CDN hostname like cdn.yoursite.com. A caching plugin rewrites the URLs; the CDN "pulls" each file from your origin on first request and caches it at the edge. This is the Bunny.net, KeyCDN, and Amazon CloudFront model, and the safest default for most sites because it can't accidentally cache a personalized page — it never sees one.

If you remember nothing else: Option B is hard to get dangerously wrong; Option A is more powerful but punishes carelessness. Many high-traffic WordPress sites end up running both — Cloudflare in front for TLS, HTTP/3, and a WAF, with full-page caching left off, plus a dedicated pull zone for assets.

Pull zones, push zones, and TTLs

For asset offload you'll almost always want a pull zone, not a push zone. A pull zone fetches files from your origin automatically the first time they're requested and caches them; you change nothing about your file storage. A push zone requires you to upload assets to the CDN yourself, which only makes sense for large media libraries or video where you want to bypass the origin entirely.

Caching behavior is governed by the Cache-Control and Expires headers your origin sends. Static assets in WordPress are fingerprinted or versioned, so set long edge TTLs — 30 days to a year is normal for CSS, JS, fonts, and images. The number that tells you whether it's working is cache hit ratio: you want it well above 90% for static content. A low hit ratio usually means your origin is sending no-cache headers or query strings are fragmenting the cache.

If you have a single origin and a global audience, enable origin shield (offered by Bunny.net, CloudFront, and others). It designates one regional edge as a middle layer so that a cache miss in Tokyo doesn't hammer your origin in Virginia — the shield absorbs the miss and fans the file out to other edges. This dramatically cuts origin load during traffic spikes.

What a CDN actually improves — and what it doesn't

Be precise about the wins, because a CDN is not a magic "make it fast" button.

TTFB drops for visitors far from your origin, because static files (and, with full-page caching, HTML) are served from a nearby edge instead of crossing oceans. A respectable target is TTFB under ~500ms, and well under 200ms for cached edge hits.
LCP (the Core Web Vitals threshold is under 2.5s) improves because your hero image and above-the-fold CSS arrive faster from the edge. This is the metric a CDN moves most visibly.
HTTP/3 over QUIC and Brotli compression come free with most modern CDNs and reduce round-trip latency, especially on flaky mobile connections.
Edge image optimization — converting to WebP or AVIF and resizing on the fly — is available from Cloudflare Images, Bunny Optimizer, and Jetpack's Site Accelerator, and can cut image payload by half or more.

What a CDN does not fix: CLS (layout shift is a front-end coding problem — set width/height on images, reserve space for ads), and INP (the under-200ms interaction threshold is about JavaScript execution, not delivery). It also won't rescue a slow, unindexed database query on an uncached page. If your bottleneck is PHP and MySQL, a CDN hides it for cached visitors but not for the logged-in admin or the checkout flow.

The WordPress-specific trap: edge HTML caching

This is where setups go from "slow" to "broken," and it only applies if you chose Option A and turned on full-page caching at the edge.

WordPress serves personalized HTML to logged-in users, commenters, and shoppers. If the edge caches that HTML indiscriminately, the first person to load a page after login can have their version — admin bar, cart contents, "Hi, Jane" greeting — served to everyone who comes next. On a WooCommerce store this is a genuine data-leak and order-integrity bug, not a cosmetic glitch.

The fix is a strict set of cache-bypass rules. Never cache, at the edge:

Anything under /wp-admin/ and /wp-login.php
Requests carrying a WordPress logged-in or comment-author cookie (wordpress_logged_in_*, comment_author_*, woocommerce_*)
WooCommerce's dynamic pages: /cart/, /checkout/, and /my-account/
The REST API and AJAX endpoints (/wp-json/, admin-ajax.php) unless you know a specific route is safe

Cloudflare's Automatic Platform Optimization (APO) for WordPress, configured through the official Cloudflare plugin, exists precisely to handle these bypass rules for you — it respects WordPress cookies and purges automatically. It remains available as of 2026, though note that Cloudflare's older Page Rules are deprecated for new accounts, so build any manual rules with the newer Cache Rules instead. If you're not comfortable reasoning about cookies and cache keys, leave full-page edge caching off and rely on a page-caching plugin at the origin plus a pull zone for assets. That combination captures most of the benefit with none of the risk.

Purging, mixed content, and CORS

Three operational details that quietly cause support tickets:

Purge on update. When you edit a post or push a theme change, the edge must drop its stale copy. The major caching plugins — W3 Total Cache, WP Rocket (with RocketCDN), and LiteSpeed Cache (with QUIC.cloud) — integrate purge hooks for popular CDNs so this happens automatically. The official Cloudflare plugin purges on content changes too. Without this wiring you'll be manually clearing the cache and wondering why your edits "aren't showing up."

Mixed content. If your CDN serves assets over HTTPS but a plugin hard-codes http:// URLs, browsers block them. Make sure your site URL and CDN hostname are both HTTPS and use a search-replace tool to fix any hard-coded protocols after a migration.

CORS for fonts. Browsers enforce cross-origin rules on web fonts. If you serve fonts from cdn.yoursite.com while pages load from yoursite.com, the CDN must send Access-Control-Allow-Origin headers or your fonts silently fail to render. Most CDNs have a one-click toggle for this; remember to flip it.

Which setup for which site

Hobby blog or brochure site: Cloudflare's free plan (orange cloud, HTTP/3, free TLS) plus Jetpack Site Accelerator for images. Zero cost, five minutes of work.
Business site on managed hosting: Use the host-integrated CDN if you're on Kinsta, WP Engine, SiteGround, or Cloudways — it's pre-configured and purges correctly. Otherwise a Bunny.net pull zone driven by WP Rocket or LiteSpeed Cache.
WooCommerce store: Cloudflare APO or your host's CDN with verified bypass rules for cart, checkout, and my-account. Test logged-in and logged-out in two browsers before launch.
High-traffic publisher: Full-site proxy (Cloudflare or Fastly) with edge full-page caching, origin shield enabled, and a tight purge integration — the configuration that lets a single origin survive a front-page traffic spike.

Pick the row that matches you, wire the bypass rules carefully if you're in row three or four, and verify cache hit ratio and LCP from a location far from your origin once it's live. That's the CDN setup every WordPress site should actually have.

The CDN Setup Every WordPress Site Should Have