Cloudflare WordPress Speed: Edge Caching Done Right

What does Cloudflare actually do for WordPress speed?

Cloudflare is a content delivery network (CDN) and reverse proxy that sits between your visitors and your WordPress host, serving cached copies of your files from data centers close to each user. Once your domain's DNS is proxied through Cloudflare (the orange cloud), every request hits one of its 300-plus edge locations first instead of traveling all the way to your origin server. For a visitor in Sydney loading a site hosted in Virginia, that's the difference between a 250ms round trip and a 20ms one.

By default Cloudflare caches your static assets: images, CSS, JavaScript, fonts, PDFs. That alone trims bandwidth off your origin and speeds up repeat loads. What it does not cache out of the box is your HTML, because WordPress generates that dynamically with PHP. So the homepage, posts, and archives still get built on your server unless you turn on full-page edge caching, which I'll cover below.

The honest framing: Cloudflare is a delivery and offload layer, not a magic backend fix. It can mask cacheable delays and cut latency for distant users, but it can't rewrite slow queries or a bloated theme. If your server TTFB is over 0.8s because of unoptimized PHP, the CDN won't move that number for a logged-in or uncached request. Pair it with real backend work and a full WordPress speed optimization pass to see the gains stick.

Free vs APO vs Pro: which Cloudflare plan do you need?

For most WordPress sites, the free plan plus the $5/month APO add-on covers 90% of the speed wins, and you don't need Pro at all. Here's how the tiers actually differ for performance, not marketing.

My rule: start free, add APO if you publish often and want hands-off HTML caching that purges in about 30 seconds after each edit. Only jump to Pro when you genuinely need Polish for automatic image compression and WebP conversion, and even then I'd usually rather compress images with ShortPixel or a dedicated plugin first because you keep control of the output. Pro's WAF and analytics are nice, but they aren't speed features.

How do you cache HTML at the edge with APO or cache rules?

You cache HTML at the edge one of two ways: turn on Automatic Platform Optimization (APO), or write a Cache Rule that tells Cloudflare to cache everything for anonymous visitors. APO is the easy path and Cache Rules is the free, manual path. Both store your rendered pages in Cloudflare's Workers KV so the next visitor gets HTML from the edge in under 60 seconds of propagation, no PHP execution at all.

To enable APO: install the official Cloudflare plugin, paste an API token, then flip on Automatic Platform Optimization in your Cloudflare dashboard under Speed. The plugin handles cache purging automatically whenever you update a post, so you don't get stale pages. Cloudflare reports APO can cut TTFB by around 70% on sites that weren't already page-cached, and that matches what I see when the origin had no full-page cache to begin with.

The free route uses the newer Cache Rules interface (which replaced Page Rules for caching). You create a rule like "if URI Path does not contain /wp-admin/ and request has no wordpress_logged_in cookie, then Eligible for cache: Yes, Edge TTL: respect origin." It's more work and you'll handle purging through the plugin or API yourself, but it costs nothing. If you already run a server-side page cache plugin, you might skip edge HTML caching entirely and just let Cloudflare serve assets.

Should you run Cloudflare and a cache plugin together?

Yes, and that's the setup I run on most sites, but each layer needs a clear job or they'll fight each other. The cache plugin handles the origin (page cache, object cache, minification preferences), and Cloudflare handles delivery and asset caching. Conflicts happen when both try to minify or both try to cache HTML without talking to each other.

The clean division I use: let your plugin (WP Rocket, LiteSpeed Cache, or FlyingPress) generate the page cache and do CSS/JS optimization at the origin, then point Cloudflare at static assets only. If you want edge HTML caching too, use APO and turn OFF the plugin's own "cache everything at Cloudflare" toggle so you don't double-cache. WP Rocket and FlyingPress both have a native Cloudflare add-on that auto-purges the edge when the origin cache clears, which keeps the two in sync.

One thing I always disable: Rocket Loader and Cloudflare's Auto Minify if your plugin already handles JS deferral and minification. Running both produces broken async ordering and the classic render-blocking warnings that send you chasing ghosts. Let one tool own each task. When in doubt about which layer caused a regression, check the cf-cache-status header to confirm whether a HIT came from the edge or your origin.

How do Brotli and HTTP/3 speed up delivery?

Brotli is a compression algorithm that shrinks text assets (HTML, CSS, JS) about 15-25% smaller than gzip, and Cloudflare applies it automatically on every plan with zero config. Smaller transfers mean faster downloads, especially on mobile networks where bandwidth is the bottleneck. You don't toggle anything; it's on by default once you're proxied.

HTTP/3 with QUIC is the transport upgrade worth enabling under Network in your dashboard. It runs over UDP instead of TCP, so it recovers from packet loss faster and removes head-of-line blocking, which helps a lot on flaky mobile and high-latency connections. I also enable HTTP/2 to Origin and 0-RTT Connection Resumption while I'm in there, since both reduce handshake overhead for returning visitors. These are quiet wins that show up in real-world field data more than in a single lab test.

If your goal is squeezing transfer size further, also turn on text compression at the origin and verify it end to end. Cloudflare compressing the edge response doesn't help if your origin sends uncompressed bytes to Cloudflare on a cache miss. I cover the origin side in the WordPress text compression guide, and it pairs neatly with the Brotli layer here.

How does Cloudflare handle image delivery and Polish?

Polish is Cloudflare's image optimization feature on the Pro plan that compresses images at the edge and can serve WebP to browsers that support it, all without touching your media library. It strips metadata, applies lossless or lossy compression, and caches the optimized version, so the first byte your visitor gets is already smaller. Mirage, also Pro, lazy-swaps low-res placeholders on slow mobile connections.

Here's my real-world judgment call though: Polish is convenient, but it optimizes whatever you upload rather than fixing oversized originals. If you upload a 3000px hero and let Polish compress it, you're still shipping a giant image with slightly smaller bytes. I'd rather resize and convert at the source, then let Cloudflare cache and deliver the already-lean file. So for sites on the free or APO plan, skip Polish and handle images properly with a dedicated image optimization workflow plus correct width and height attributes to avoid layout shift.

Whichever path you pick, the win is the same: Cloudflare caches your images at the edge and serves them from a nearby data center, so repeat and global visitors skip the origin entirely. That's the part of the CDN that delivers value on every plan, free included.

Which URLs must you exclude from caching?

You must never edge-cache the cart, checkout, my-account, wp-admin, wp-login, or any URL that returns user-specific or session-specific content. Caching a personalized page means visitor B can see visitor A's cart, prices, or login state, which is the single most damaging mistake people make when they enable full-page caching on Cloudflare.

APO handles most of this automatically by bypassing cache when a logged-in or WooCommerce session cookie is present. But if you're using free Cache Rules, you set the exclusions yourself. The cookie-based bypass list I always include is:

• wordpress_logged_in_* (any logged-in user)
• wp-postpass_* (password-protected posts)
• woocommerce_cart_hash and woocommerce_items_in_cart (active cart)
• wp_woocommerce_session_* (WooCommerce session)
• edd_items_in_cart (Easy Digital Downloads)
• comment_author_* (commenters)

I also add path-based bypasses for /cart/, /checkout/, /my-account/, /wp-admin/, and /wp-json/. For stores, this is non-negotiable, and it's exactly what I walk through in the WooCommerce speed optimization guide. Get the exclusions right once and edge caching becomes safe to leave on.

What are the most common Cloudflare WordPress mistakes?

The most common mistakes are caching dynamic pages, expecting the CDN to fix slow PHP, triggering mixed-content errors with the wrong SSL mode, and forgetting to purge after big changes. Each one has a clean fix once you know the symptom.

Caching logged-in or cart pages: covered above, but worth repeating because it's the one that breaks stores. Always verify your cookie bypass works by adding a product to the cart and confirming the response shows cf-cache-status: BYPASS, not HIT. Assuming the CDN fixes slow hosting: if your host is the bottleneck, a cache miss still hits a slow origin. Cloudflare hides it for cached hits and exposes it on every uncached request.

Mixed content warnings: set SSL/TLS mode to Full (Strict), enable Automatic HTTPS Rewrites and "Always Use HTTPS" so internal http:// assets get upgraded instead of getting blocked by the browser. Using Flexible mode causes redirect loops, so avoid it. Forgetting to purge: after a theme change, plugin update, or CSS edit, purge the Cloudflare cache (the plugin does this for content edits, but layout and asset changes often need a manual "Purge Everything"). Stale CSS is the reason a fix "isn't showing up" half the time.

How do you confirm Cloudflare caching is working?

You confirm caching by reading the response headers, specifically cf-cache-status, which tells you exactly what Cloudflare did with each request. Open your browser DevTools, go to the Network tab, reload the page, click the document request, and check Response Headers. A second load should show cf-cache-status: HIT for cached pages and assets.

The values you'll see: HIT (served from edge cache), MISS (fetched from origin, now cached), BYPASS (intentionally not cached, correct for cart and admin), DYNAMIC (not eligible for cache), and EXPIRED (TTL lapsed, refetched). For APO sites, also look for cf-apo-via: cache to confirm HTML is being served from the edge. From the command line, curl -I https://yoursite.com shows the same headers without a browser.

Then validate the actual speed impact with a tool that tests from multiple regions, since a single-location test from near your origin won't reveal the global benefit. Run a before-and-after in PageSpeed Insights and a multi-location test, and watch field metrics like LCP and TTFB over a few days. If repeat visits and distant-region loads improved but a local first byte didn't budge, that's expected: the edge cache helps reach and repeat traffic, not your origin's compute time.

My checklist for Cloudflare WordPress Speed

Guides related to Cloudflare WordPress Speed

I use internal links to keep the WordPress speed topic map clear. If this article is close to your problem but not exact, one of these pages is probably the better next step.

What do people ask about Cloudflare WordPress Speed?