A WooCommerce store can have quick product pages while cart and checkout remain slow. Shared HTML caching may reduce origin load, but a poorly scoped rule can serve one customer’s session-dependent response to another. This guide treats cache configuration as a correctness and data-separation problem as well as a performance decision.
The following workflow explains what WordPress HTML can be shared at a CDN, which WooCommerce requests must bypass caching, and how cache keys, TTLs, purges and testing fit together. Apply the exclusions at the origin page cache as well as the CDN. A short TTL does not make sharing a personal response safe.
Why HTML Caching on a CDN Is Tricky with WordPress
Here’s the thing about WordPress: it’s a dynamic app pretending to be a static site most of the time. When you’re logged out, most pages can look static for a while. But the moment you add logins, comments, WooCommerce carts, or anything personalized, you’re juggling cookies, sessions, and fragments that change per user. That’s exactly where CDN HTML caching gets tricky. A CDN is brilliant at caching static files—images, CSS, and JS. But HTML? That’s where we need tact, not brute force.
Separate public reusable content from content that depends on the current visitor. Versioned or content-hashed static files can have long lifetimes; files that change under the same URL need a compatible expiry or invalidation strategy. HTML requires its own policy, because the same URL can return a public page to one visitor and personal data to another.
Start with inspected public pages such as articles and non-personalized categories. Keep login, account, cart, checkout, add-to-cart actions and previews dynamic. Then add request-cookie and authorization exclusions, response-header checks and tests of actual content. A list of URL names alone does not cover every session or plugin behavior.
The Golden Rules: What to Cache, What to Bypass
Cache Everything (HTML) — But Only Where It Makes Sense
Edge HTML caching can reduce origin work and response time for public, reusable representations. Candidate pages include posts, landing pages and categories only after checking their templates, widgets and response headers. Product pages with member pricing, location-dependent tax, currency or personal widgets need correct variants or bypass. Public product data also needs a defined acceptable staleness window.
Set the HTML TTL according to acceptable content delay and a verified purge workflow. For example, 5–30 minutes may be a starting range for some public content, not a universal recommendation for prices or campaigns. Private responses stay out of shared cache at any TTL. Do not promise instant global purge; verify its completion and account for browser caching separately.
Bypass for Anything with a Session, Action, or Personalization
Bypass rules are your seatbelt. The hard “do not cache” zones typically include:
– The actual wp-admin, wp-login.php, admin-ajax and preview routes.
– Real cart, checkout, account, payment-return and related endpoints, including localized or customized paths.
– add-to-cart, wc-ajax, wc-api and other action query parameters, regardless of parameter order.
– Session-specific Store API calls, including cart and checkout GET requests; keep unreviewed REST routes outside shared caching.
– Requests with authentication, session or personalization cookies, or an Authorization header.
– Non-GET requests in this conservative HTML policy, and responses marked private/no-store or setting cookies.
Client-side rendering, ESI or a supported edge function can separate a public template from personal fragments, but only with a deliberate design. The cached template must contain no customer-specific fields or session data; private fragment endpoints must preserve authorization and avoid shared storage. Do not put the assembled personal response back into the shared cache. Until those properties are verified, bypass the page.
Let the Origin Speak, But Teach the CDN the Local Dialect
Respect origin cacheability before trying to improve the hit ratio. private excludes shared storage, no-store prevents storage, and no-cache requires revalidation; they are not interchangeable. Investigate why a plugin emits a restrictive header instead of blindly overriding it with an edge TTL. In this general WooCommerce policy, do not cache Set-Cookie responses, including the first response that creates a session before the request has any session cookie.
Curious about the broader benefits of a CDN and how it fits into the bigger picture? See what a content delivery network really is and why it speeds things up.
WooCommerce-Safe Caching: Cookies, Cart, and Checkout Without Tears
WooCommerce is where many caching plans go to die. It introduces cookies that help track sessions and carts, which is magical for conversions and disastrous for naive caching. The goal isn’t to avoid caching altogether—it’s to cache where we can and bypass where we must.
Know Your Cookies (So You Can Bypass the Right Requests)
At minimum, you want to bypass when these appear:
– wordpress_logged_in_ and any other authentication cookie used by the application.
– wp_woocommerce_session_, woocommerce_cart_hash and woocommerce_items_in_cart.
– wp-postpass_ for unlocked password-protected content.
– comment_author_ cookie families when templates prefill commenter details.
– woocommerce_recently_viewed, store_notice and plugin-specific cookies when they alter the HTML; these are conditional personalization signals, not a complete list.
Match cookie names or their variable-suffix families correctly. Configure request-time bypass before a cached public response can be reused, and also prevent personal origin responses from filling shared cache. Check origin/plugin caches too: a CDN bypass does not guarantee a fresh response if the origin has its own incorrectly shared page cache. Authorization-based requests need equivalent handling.
For a handy refresher on WooCommerce cookies, see the official reference: WooCommerce cookies explained.
Protect Cart, Checkout, and Account Endpoints
Use the store’s configured cart, checkout and account URLs, not just the English examples /cart/, /checkout/ and /my-account/. Include their sub-endpoints and payment callbacks. Bypass add-to-cart and wc-ajax/wc-api actions before stripping or ignoring query parameters. WooCommerce Blocks can use Store API cart and checkout routes under /wp-json/wc/store/v1, including GET requests; inspect those paths and any alternative rest_route query form too.
Logged-In vs. Logged-Out: Make the Split
Bypass shared HTML caching for wordpress_logged_in_ requests. If a membership site needs additional optimization, design a genuinely public template and separate authorized fragments as described above. A Worker or ESI tag does not automatically make an existing personalized page safe to share; validate the template, fragment and final response independently.
Prevent Staleness Without Punishing the Origin
Balance origin load against the acceptable age of prices, stock and promotions. A product update can affect its own page, categories, homepage panels, related-product sections and language/currency variants. Coordinate origin page-cache invalidation with CDN purging so the edge does not refill from stale origin HTML. Test that newly published data is visible rather than assuming a purge request completed everywhere.
For deeper server-side tuning that pairs nicely with edge caching, see the server-side secrets that make WordPress fly. Edge and origin optimizations together are where the real magic happens.
Edge Settings That Make a Real Difference
Cache Keys: Keep Them Clean, But Not Blind
A cache key decides which requests share a stored representation. Preserve host, path and every relevant content variant; host + path alone can merge different pagination, language, currency, filtering or sorting. Exclude only parameters proven not to alter HTML, redirects or headers. Unknown parameters should be reviewed or bypassed rather than silently ignored. A marketing parameter can be functional when a campaign plugin changes content from it.
Cache TTL: Origin vs. Edge
Long TTLs suit immutable, versioned assets. Choose HTML freshness according to the content’s update requirements and tested invalidation, with 5–30 minutes only an example for suitable public pages. Edge and browser TTLs differ: CDN purge does not remove a browser’s stored response. Changing the configured TTL also does not reliably shorten the lifetime of objects already stored everywhere; invalidate when a timely switch is required.
Bypass on Cookie, Bypass on Header
Use request cookies and authorization to bypass before cache lookup. An application response header can prevent storage only if the CDN is explicitly configured to honor it; it cannot retroactively prevent a hit already served without contacting the origin. X-Bypass-Cache is not a universal standard. Prefer correct Cache-Control semantics plus the CDN’s documented request-time and response-time controls.
Respect the Right Methods and Endpoints
Limit this shared HTML policy to inspected public GET responses; GET alone still does not establish safety. Exclude state-changing methods, login/admin and AJAX requests, session-specific REST/Store API endpoints and previews. Do not rely on a CDN’s defaults after introducing a broad override or custom Worker; verify effective behavior for each method and route.
Device Differences, Geo, and Personalization
If mobile and desktop use the same responsive HTML, no device variant is needed. When the server actually changes HTML by device, country, language or currency, represent the same decision in the cache key or bypass. Vary is not automatically honored for every field by every CDN. Keep variants bounded; any dynamically fetched personal fragments still require the separate protections described above.
Security Headers and Caching Play Nicely
Security headers must match cached HTML too. In a CSP nonce design, the header and document must use the same correct nonce; distributing a reused nonce in shared HTML needs separate design review. Enable HSTS only when HTTPS works for its entire chosen scope. The HTTP security headers guide covers these controls. Their presence alone is not a search-ranking or security guarantee.
Practical Playbooks: Cloudflare, Fastly, and CloudFront Mindset
The public/private separation applies across CDNs, but rule ordering, origin-header overrides, custom keys and fragment support differ. Translate each requirement into supported settings and test the result; similar labels are not proof of equivalent behavior.
The “Cache HTML with Guardrails” Recipe
Start with a rule set like this:
– Allow shared HTML only for inspected public paths and non-personalized GET requests; do not treat /* as an allowlist.
– Select TTL from acceptable staleness and test purge of related pages/variants.
– Exclude only verified non-functional tracking parameters from the key; retain or bypass functional and unknown parameters.
– Bypass actual localized admin/login, cart, checkout, account and preview routes, payment callbacks and action queries.
– Bypass authentication, cart/session, password-access and relevant personalization cookies, plus Authorization requests.
– Keep session-specific REST and Store API data dynamic, including GET calls.
– Preserve private/no-store and Set-Cookie protections, and confirm exclusions win over broad rules in every cache layer.
Test in two separate customer sessions, a clean guest browser and an authenticated account. Run both cache-fill orders: personal request before anonymous request, then anonymous before personal. Inspect the body, Set-Cookie and cache-status headers over repeated requests. Test adding/removing items, coupons, logout, previews, language/currency switches and checkout with a test payment method.
Cloudflare: Cache Rules and Bypass on Cookie
Cloudflare Cache Rules can enable HTML caching for selected public requests and exclude sensitive ones. For conflicting settings, the last matching Cache Rule wins; ensure a later broad rule cannot undo bypass. Custom key options depend on plan, and Workers can introduce separate behavior. Check the Cloudflare cache documentation for the features actually available. Do not use a Worker to cache an assembled personalized response merely because its public template was cacheable.
Fastly and CloudFront: Same Song, Different Instruments
Fastly can use VCL and surrogate keys to control caching and invalidation; ESI can assemble independently handled fragments where supported. CloudFront uses path behaviors, cache policies and separate origin request policies. Use disabled caching on critical paths. A positive CloudFront Minimum TTL can override private/no-store/no-cache; cookie forwarding or inclusion in a key is not itself bypass. Session requests on otherwise public paths need an explicit supported design, or keep HTML caching disabled for that scope. ESI support and syntax are not interchangeable across providers.
Don’t Forget Purge Discipline
Automate purges for publish/update and for product, stock, price, menu and promotion changes that affect public HTML. Include related listings, widgets and variants, and coordinate origin invalidation first. Tags can help group dependencies where supported. Use a broad purge when the actual change is broad; prefer neither global nor selective purge blindly. Measure refill load and confirm the new representation.
Testing, Purging, and Real-World Troubleshooting
A/B Your Journey: Guest, Logged-In, Customer with Cart
Use independent guest, authenticated and cart sessions to check both body content and headers. Test the first request that creates a session, not only requests that already carry a cart cookie. Repeat with the site’s real device, language, currency and location variants. Include expired sessions, comment forms and previews when those templates or routes are in scope.
Headers: Your Truth Serum
A HIT shows reuse; a single MISS does not prove bypass because it can fill the cache for the next request. Age reports elapsed cache age, not remaining TTL. Inspect repeated GETs, origin-cache indicators and the actual body, especially when Workers sit in front of the CDN cache. If a personal response is shared, disable the affected HTML rule and purge the exposed representations in every relevant cache layer before retesting.
Investigating a sudden performance regression
A cold cache or broad purge can increase origin load, but do not assume it is the cause of every slowdown. Compare hit ratio, origin latency, database/PHP load, errors and third-party calls. Warm only verified public anonymous URLs at a controlled rate. One warm-up location does not fill all edge points or all variants, and excessive prefetch concurrency can make the origin slower.
Edge Security and Availability Still Matter
Performance isn’t the only reason to involve a CDN. DDoS protection, smart routing, and global resilience pay the bills when traffic goes weird. For background, see what DDoS attacks are and how to protect your site and how Anycast DNS and automatic failover keep your site up when everything else is wobbly. Your cache is only heroic if your site is reachable.
When to Consider Edge Workers or ESI
Consider Workers or ESI when a measured need justifies separating public templates from dynamic fragments. Mini-carts, customer greetings and region pricing need correct session handling and explicit rules for which data may be reused. Support differs by provider, and both fragment and assembled-response behavior need independent tests. Keep the ordinary bypass policy until the more advanced design is proven.
Bringing It All Together
A useful rollout begins with a small set of public pages, defined freshness, working purge dependencies and explicit exclusions. Expand only after two independent customer sessions remain separate through cart, checkout and account changes. Cache hit rate is one measurement; correct body content, update visibility and origin capacity are equally necessary.
If you’re staring at your own setup wondering where to begin, start small: turn on HTML caching only for safe paths, and add strict bypass rules for WooCommerce paths and cookies. Then tighten the cache key, exclude only verified non-functional parameters, and test guest vs. logged-in vs. cart user journeys. When freshness requirements allow, adjust the TTL and wire up purges for publishing, stock, prices, promotions and their dependent pages. If you need a refresher on the foundation pieces that make all this smoother, don’t miss how a CDN really speeds things up and the server-side optimizations that supercharge WordPress. And if you’re tightening up the security side while you’re at it, keep that security headers checklist handy and read up on staying up even when things go sideways.
Keep the verified rule set and test cases with your deployment notes. Recheck them after adding a payment, membership, currency or cache plugin, because those changes can introduce new session-dependent paths and responses.
