Performance
Hosting, cache and CDN for WordPress stores
WordPress cache CDN is the stack of full-page cache, object cache, a CDN for static assets, and the rules that keep WooCommerce cart, checkout and account pages dynamic so a customer never sees someone else’s basket. Hosting is the machine and PHP workers. Cache is what you dare to store. CDN is where the bytes live.
I am a Gold Coast web developer. Eighteen years of WordPress and WooCommerce work means I have inherited “we installed a cache plugin” more often than I have inherited a working purge. Official performance notes on WordPress optimisation cover caching, CDN and object cache in admin language. This is the store version: what must never be cached as HTML, and what should be.
What WordPress cache CDN has to do on a store
WordPress cache CDN work on a store is three layers that people collapse into one plugin screenshot.
Full-page cache (or edge cache) stores HTML for anonymous catalogue pages. That is the win for TTFB on PLP and PDP. Logged-in users, cart, checkout, my-account, and anything with a nonce that is user-specific should bypass. If you cache checkout HTML, you will leak carts or serve a stale nonce and payments fail.
Object cache (Redis or Memcached) stores database-shaped objects: options, post meta, sessions if you go that way. WooCommerce without an object cache on a busy catalogue will repeat the same queries. Object cache is not a CDN. It does not replace page cache.
CDN stores and serves images, CSS, JS, fonts, and sometimes HTML if you use an edge cache. For images, see WordPress AVIF and WebP. For order volume and admin, HPOS belongs in WooCommerce high-performance order storage. This page is the request path.
Hosting: PHP version, workers, MySQL, disk, opcache. A CDN in front of a dying PHP box still waits on origin for uncached HTML. WooCommerce checkout is origin. Budget workers for peak, not for the homepage.
Skanvi is a WooCommerce furniture store I shipped as contract work on an agency team: large photography, editorial catalogue, a first-order path. BridgeWorx is WordPress and WooCommerce ticketing: events, grids, purchase. Both need page cache on public content and a hard bypass on ticket/checkout flows.
Why WordPress cache CDN still matters in 2026
Block themes, Interactivity API, and Woo blocks do not remove the need for cache. They change the HTML and the JS. A CDN still has to send the LCP image. PHP still has to build cart.
Plugins that claim “one click CDN” often put a query-stringed HTML cache in front of Woo and then sell you a cache-exclude list. The list is never complete. A sale badge plugin sets a cookie. The page cache now fragments into a thousand copies or bypasses everything. TTFB returns to origin.
INP is not fixed by a CDN. A CDN can fix LCP bytes and TTFB. INP is main-thread JS. Do not promise Core Web Vitals from Cloudflare alone.
Australian origin with a US-only host is a TTFB tax for local shoppers. If the catalogue is AU traffic, host close to AU or use an edge cache that actually holds HTML in SYD. A CDN that only does images still leaves HTML on a sleepy origin.
How a sane WordPress cache CDN path looks
Anonymous GET on a product URL: edge or Varnish or nginx fastcgi_cache or a page-cache plugin with a real purge. Cache-Control on HTML should be short enough that a price change is not a scandal, or you purge on product save. I prefer purge-on-save over 12-hour HTML if merchandising is active.
Static assets: long cache, hashed filenames. CDN in front. HTTPS. No query-string cache-busting that the CDN treats as unique forever without purge.
POST, cart cookies, woocommerce_items_in_cart, logged-in wordpress_logged_in: bypass page cache. Mini-cart that is ESI or JS-fetched from an uncached endpoint is how you keep HTML cached while the count stays right. Mini-cart that is in the HTML is why people disable page cache.
Admin-ajax and wc-ajax: do not cache. Rate-limit abuse. Cart fragments polling is an INP and origin tax. Reduce it if you can.
Checkout, pay, order-received: never page-cache. Never CDN-cache as HTML. Assets yes, HTML no.
Object cache: persistent Redis. Drop-in in place. Do not use a file-based object cache on a multi-node host. Sessions: if you use Redis for sessions, size and TTL them. Do not store sessions on local disk behind a load balancer.
CDN SSL and mixed content: if the CDN is on a different host, theme URLs must be rewritten once. Double rewrites fight.
Cron and cache are related because stock, scheduled sales and failed payment retries all write while HTML is still being served. A sale that starts at midnight has to purge or bypass the tiles that still show yesterday’s price. I would rather a short HTML TTL on PLP during a campaign than a clever purge that misses a widgetised “featured” block.
WP-CLI and deploy: after a release, hashed CSS/JS must be new URLs. If the theme still prints style.css?ver=1.0, the CDN will keep the old file. Content-hash the filename or raise the version on every build. I do the same for AVIF derivatives so a recoded hero is not stuck behind a 30-day image TTL.
Staging must not share the production CDN cache key. I have seen a DISALLOW robots staging HTML served to production because the host used one pull zone and forgot the Host header. Separate zone, or a cache key that includes host, or you will debug ghosts.
Purge: product update purges that product and the collections it is on. Category merchandising purges the PLP. A “purge all” after every save is not a strategy. It is a way to make the CDN pointless during a merchandising session.
Production checklist for WordPress cache CDN
- Draw the request types: anonymous HTML, logged-in HTML, cart/checkout HTML, assets, AJAX, admin.
- Put page cache only on anonymous catalogue and content. Prove it with two browsers and a cookie-less curl.
- Confirm cart and checkout set cookies that bypass. Add a test SKU, view cart on a second device, you must not see that cart on a third anonymous session.
- Put Redis (or equivalent) on and verify with a hit rate after warm-up, not on an empty staging.
- Point images and hashed assets at the CDN. Check AVIF/WebP if you use them, including cache keys for Accept if you negotiate format.
- Set purge hooks for product, stock, price, and menu. Test a price change.
- Load-test origin PHP workers on add-to-cart, not only on homepage GET.
- Exclude preview, query-string sort if those are personalised, and any nonce HTML.
- Monitor origin 5xx and CDN 404s after a deploy (hashed files).
- Document who can purge all, and who should not.
What breaks in WordPress cache CDN setups
Cached HTML with another user’s cart or name. Stop everything. That is a privacy incident.
Cached nonce on checkout. Place order fails randomly. Customers retry. Duplicates.
Stale stock: sold-out on the site, still buyable in cache. Purge on stock change or keep stock AJAX uncached.
CDN caching HTML for /cart because someone set a 30-day TTL on everything.
Plugin that sets a unique cookie per visitor for A/B. Page cache hit rate collapses. You pay origin. You think the CDN is broken.
Object cache serialization errors after a plugin update. Site whitescreens. Have a drop-in disable path.
Multiple page-cache plugins. They fight. Pick one.
Purging only the PDP after a price change, leaving the PLP tile stale.
BridgeWorx tickets: caching a sold-out event page is annoying. Caching a checkout nonce is fatal. Skanvi: caching a huge PDP HTML is good if the gallery URLs are CDN-hashed and the price is correct.
HPOS: faster admin/order queries, not a substitute for page cache. Do both when the store needs both.
How I measure WordPress cache CDN
TTFB on anonymous PDP from the customer’s region, cached versus cold.
Hit ratio on the page cache and on Redis.
Origin CPU during a sale, especially add-to-cart.
Error rate on checkout.
LCP: CDN should help the image. If LCP is still a 2MB original, read the image post. Cache will not invent derivatives.
I do not invent conversion percentages for cache work. I will cite Skanvi and BridgeWorx as live stacks that have to hold photography or ticketing without freezing PHP.
Related work on this site
Skanvi is WooCommerce furniture with an editorial catalogue and large stills. Page cache and a CDN for media are how that photography stays on a phone. BridgeWorx is WordPress ticketing: events must stay purchasable, which means checkout stays uncached and origin stays healthy.
For order storage under load, read WooCommerce HPOS. For the media formats the CDN should actually serve, read WordPress AVIF and WebP image delivery.
FAQ
Can one plugin provide a full WordPress cache CDN setup?
A plugin can do page cache, and a host can do CDN. WordPress cache CDN for a store still needs bypass rules, Redis, and purge discipline. One screenshot is not a stack.
Should I cache WooCommerce HTML at the CDN edge?
Cache anonymous PLP and PDP HTML if you can purge on merchandising and stock. Never cache cart, checkout, account or nonce HTML. If your CDN cannot distinguish, do not cache HTML there.
Does WordPress cache CDN fix INP on checkout?
No. WordPress cache CDN is TTFB and asset delivery. Checkout INP is JavaScript and plugins. Keep checkout off page cache and cut JS separately.
Where is the official WordPress cache CDN documentation?
WordPress’s optimisation documentation covers caching, object cache and CDNs. Host and CDN vendors have their own WooCommerce exclude lists. Verify those lists on a real cart, not only on a blog post.
Keep reading
Contact if you want this kind of work on a live store.