WooCommerce CDN: a setup guide for store owners

A WooCommerce store runs well behind a CDN when the edge serves static files and the catalog pages guests see, while everything personal or transactional goes straight to your server: cart, checkout, the account area, visitors with an active cart, AJAX and API calls, and payment callbacks. Getting those bypass conditions right, keeping prices fresh with targeted purges and testing a real order are most of the setup work. For the rest of store performance (caching plugins, database, background jobs), see the guide on how to speed up WooCommerce.

Two ways to put a CDN in front of a store

• Asset CDN. A plugin rewrites image, CSS and JavaScript URLs to a CDN hostname, while every page still comes from your server. Low risk, because no page is shared between shoppers, but the slowest part, generating the HTML, stays untouched.
• Full-site proxy. Every request passes through the edge, HTML included, so a cached product page never reaches PHP or the database. That is where the bigger gains are, and where WooCommerce needs care: the edge is a shared cache, and one wrong rule means shopper B sees shopper A's cart.

The rest of this guide is about the second setup. If you are still comparing providers, the guide on choosing a WordPress CDN covers the criteria.

What the edge can safely cache

"For guests only" is the key phrase. The same product URL can look different to a logged-in customer or to someone with items in the cart, and the edge must be able to tell these requests apart.

Query strings

Tracking parameters such as utm_source create a separate cache entry per variation, so a campaign can quietly turn hits into misses. Parameters that change the content, such as orderby or layered navigation filters, legitimately need their own entries.

What must always reach your server

Pages

WooCommerce's guide to configuring caching plugins names Cart, Checkout and My Account as pages to exclude. That includes everything below them, such as /checkout/order-received/ after payment and the order and address pages under /my-account/. If you renamed these pages or run a multilingual store, every slug and language version counts.

WooCommerce helps here: on the cart, checkout and account pages it sends Cache-Control headers that forbid caching. A CDN that respects origin headers will not store them. Check that a caching or security plugin on your site does not overwrite those headers.

Cookies

Headers only cover those three pages. A product page viewed by someone with a full cart has normal, cacheable headers, yet may render their mini cart, so the bypass also has to depend on cookies. The ones WooCommerce lists are:

• woocommerce_cart_hash and woocommerce_items_in_cart (set once something is in the cart)
• wp_woocommerce_session_* (the customer session)
• woocommerce_recently_viewed and store_notice[notice id] (only relevant if you use the recently viewed products widget or the store notice)

Add the WordPress login cookie wordpress_logged_in_*, so logged-in customers and staff always get fresh pages.

Endpoints

• ?wc-ajax= requests, used for adding to cart, applying coupons and refreshing the checkout
• /wp-admin/, admin-ajax.php and wp-login.php
• Links with ?add-to-cart=
• The Store API under /wp-json/wc/store/v1/, which powers the block-based Cart and Checkout. Its responses reflect the current customer's session.
• The authenticated REST API under /wp-json/wc/v3/, used by ERP, inventory and marketplace integrations
• Payment callbacks (more on those below)

The mini cart on cached pages

With a classic theme, the mini cart count on a cached page is filled in afterwards by the cart fragments script, which calls ?wc-ajax=get_refreshed_fragments and keeps the result in the browser's session storage. Block themes load cart data through their own requests instead, which must stay uncached just the same. The page can be cached precisely because the personal part arrives through a separate, uncached request. If that request gets cached, every visitor sees the same cart count. Whether you need cart fragments at all is covered in the WooCommerce speed guide.

Prices, currencies and locations

A shared cache only works if everything that changes a page is visible in the URL or handled by a bypass. Cookies and IP addresses are invisible to a URL-based cache key.

• Geolocation. With plain "Geolocate" as the default customer location, prices are rendered for the visitor's country on the server, so behind a shared cache the first visitor's country decides what everyone sees. WooCommerce's general settings documentation describes "Geolocate (with page caching support)" for this case: it geolocates via AJAX and appends a ?v= parameter to URLs. Each variant becomes its own cache entry, so expect more misses.
• Currency switchers. Many store the chosen currency in a cookie. If that cookie does not trigger a bypass, a cached page shows whatever currency it was first rendered in. Prefer a switcher that puts the currency in the URL or loads prices client-side, and check its caching documentation.
• Customer-specific prices. Wholesale or role-based pricing is usually shown only to logged-in users, who bypass the cache anyway. Make sure the price display really depends on login and not on a separate cookie.

Keeping stock and prices fresh

Choose HTML lifetimes by how much a stale page costs you. A content page can stay cached for hours; a product page with fast-moving stock should expire sooner or be purged on every change.

• Single product edits. Purge the product URL, the category pages it appears on, the shop page, and the homepage if the product is featured there.
• Imports and ERP syncs. Let the import job trigger URL purges through your CDN's API for exactly the products it changed, instead of waiting for pages to expire.
• Scheduled sales. A sale price that starts at midnight does not reach a cached page by itself. Schedule a purge for that moment.
• Sitewide changes. After a theme update or storewide promotion, purge everything, then warm your top categories and bestsellers.

Whether purging happens automatically depends on your setup. Either way, spot-check the response headers after a change.

Payment callbacks and the firewall

Payment providers confirm payments by calling your store server to server. WooCommerce's Payment Gateway API handles these via wc-api URLs, in the form /wc-api/<callback>/ or /?wc-api=<callback>. Many gateway plugins also register webhook routes under /wp-json/. If a callback fails, orders stay "pending payment" even though the customer paid.

These requests must never be cached, and just as important, they must never be blocked:

• Country rules. A provider's servers may call from a country you block or challenge sitewide.
• CAPTCHA challenges. A server cannot solve a CAPTCHA, so keep challenge rules to paths humans use.
• Rate limits. Webhooks can arrive in bursts, for example after a batch of refunds. Size per-IP limits accordingly.
• Bot rules. Callbacks and ERP integrations are automated clients. Check that bot rulesets don't flag them.

A test plan for the switch

Run it on staging if you can, and again right after the nameserver change (see changing nameservers without downtime).

1. Guest product page. Request it twice. The second response should be a cache hit.
2. Cart and checkout. As a guest, they must show a bypass or miss, never a hit.
3. Active cart. Add a product and reload a product page. It must not be a hit, and the mini cart must show your item.
4. Two browsers. Fill the cart in browser A. Browser B must still see an empty cart.
5. Logged-in customer. Browse the shop and account area. Nothing should come from the shared cache.
6. Test payment. Complete an order in the gateway's sandbox or test mode and confirm the order status moves on from "pending payment". That proves the callback got through.
7. Purge. Change a price, purge the URL and check the new price appears.

For the header checks, send the request once without cookies and once with a cart cookie:

curl -sI https://shop.example.com/product/example/ | grep -i -E "cache|age"
curl -sI -H "Cookie: woocommerce_items_in_cart=1" https://shop.example.com/product/example/ | grep -i cache

The second request should not come back as a hit. Once the functional tests pass, compare speed before and after with a tool such as corewebvitals.page, which shows real-user field data and a lab run for mobile and desktop.

How fast.site helps

fast.site is a full-site proxy that sits in front of your existing WooCommerce hosting. You keep your host, add your domain in the dashboard and switch your nameservers to fast.site. From then on fast.site manages your DNS, so all existing records, including MX records for your store's email, need to be in the fast.site DNS zone.

Fast Edge Cache™ serves guest-facing product, category and content pages from the edge in the regions included in your plan, and a cache HIT never reaches your server. fast.site respects your origin's Cache-Control headers, and private or dynamic responses such as cart, checkout and logged-in sessions show fs-cache: BYPASS, so you can verify every step of the test plan above (see checking the cache). After imports or price changes, you purge individual URLs or the whole domain in the dashboard, with a purge log, or via the API from your own scripts.

At the edge, fast.site also converts product images to WebP for supporting browsers (AVIF depending on plan) and filters HTTP floods and bad bots before they reach your store, with firewall rules you control. Details are on the WooCommerce page.

Measure your store before and after on your own pages, including a complete test order. You can start with a free 7-day trial.

FAQ

Do I need a CDN for WooCommerce?

Not every store does. If most customers are close to your server and pages are already fast, better hosting or an asset CDN may be enough. A full-site CDN pays off most with visitors in several regions, campaign traffic spikes or a struggling server.

Can a CDN cache WooCommerce product pages?

Yes, for guests. Product, category and shop pages can be cached as long as requests with WooCommerce cart or session cookies and logged-in users bypass the cache. Purge product URLs when price or stock changes.

Will a CDN break my WooCommerce checkout?

Not if cart, checkout, account pages, wc-ajax requests, the Store API and payment callbacks bypass the cache and are not blocked by firewall rules. Test a full order with a sandbox payment after every configuration change.

Should I keep my caching plugin with a CDN?

Often yes. A page caching plugin speeds up the requests that do reach your server, such as cache misses. Make sure the plugin and the CDN agree on exclusions, and purge both after changes.