Getting WooCommerce to perform well on a CDN is not the same as getting a blog to perform well on a CDN. A blog is stateless — every visitor sees the same content, so caching is straightforward. WooCommerce is different. It is a dynamic application that tracks cart state, user sessions, pricing, stock levels, and personalised content in real time. Cache the wrong things and your customers will see empty carts, stale prices, or worse — someone else’s checkout data.
QUIC.cloud is the CDN built specifically for LiteSpeed Web Server and LiteSpeed-based hosting stacks. Unlike generic CDNs such as Cloudflare or BunnyCDN, QUIC.cloud integrates deeply with LiteSpeed Cache for WordPress (LSCache), which means it understands WordPress and WooCommerce at the application layer rather than treating every request as a generic HTTP transaction. That is a meaningful advantage — but it also means there are more configuration decisions to get right.
A CDN caches a response and serves that cached copy to subsequent visitors. This is enormously efficient for static assets — images, CSS, JavaScript — where the response is identical for every request. WooCommerce complicates this because a large portion of its pages are not identical across visitors: the cart page shows a user’s specific items, the checkout page is personal and transactional, the My Account area shows order history, and product pages can show personalised pricing or stock messages that change frequently.
If a CDN caches a response that contains personalised or session-specific content and then serves that cached response to a different user, the result ranges from broken (empty cart on checkout) to a serious data leak (user A seeing user B’s account details). LiteSpeed Cache and QUIC.cloud are designed to handle this correctly — but only if you understand and respect the rules.
QUIC.cloud is not a standalone CDN that operates independently of your server. It works in tandem with the LiteSpeed Cache plugin (LSCache) installed on WordPress. LSCache handles page-level caching at the server and generates the cache vary headers and ESI (Edge Side Includes) instructions that tell QUIC.cloud exactly how to handle each response. The two systems communicate through response headers such as X-LiteSpeed-Cache-Control, X-LiteSpeed-Vary, and X-LiteSpeed-Tag. The practical implication: configuring caching purely from the QUIC.cloud dashboard is the wrong approach. The right place to define WooCommerce caching behaviour is primarily within LSCache settings.
Static assets are the most straightforward category and where QUIC.cloud provides its highest leverage with zero risk. Product images, CSS files, JavaScript files, web fonts, SVG files, and PDF downloads should all be aggressively cached at the CDN edge with long TTLs (24 hours or more). Your origin server should rarely be involved in serving these files once they are cached.
Standard WooCommerce product pages can be cached at the page level, but with important conditions. Cache product pages for visitors who have no session cookies set. LSCache handles this by not caching pages once WooCommerce session cookies are present — specifically woocommerce_cart_hash, woocommerce_items_in_cart, or any logged-in WordPress cookies. The result: your product pages load extremely fast for the majority of visitors who are browsing rather than mid-transaction. TTL recommendation: 1-4 hours, with stores running frequent flash sales using shorter TTLs or cache purging on product save.
Shop and category pages follow the same logic — safe to cache for guest visitors, bypassed for logged-in users or users with cart sessions. One consideration: if you use WooCommerce’s built-in sorting and filtering, each URL variant with query parameters should either be cached separately or excluded. Faceted filtering via plugins generates large numbers of URL variants that can bloat your cache.
WooCommerce’s dynamic cart counter in the site header is traditionally one of the biggest obstacles to full-page caching. LiteSpeed Cache solves this with ESI (Edge Side Includes). When ESI is enabled, LSCache marks the cart fragment as a separate sub-request that is assembled dynamically even when the rest of the page is served from cache. QUIC.cloud supports ESI natively. Without ESI, you are forced to either not cache page HTML or accept a broken cart counter.
Now for what QUIC.cloud should never cache. The cart page (/cart/) is entirely personal — it shows what a specific user has in their basket and changes the moment they add, remove, or update a product. The checkout page (/checkout/) must absolutely never be cached — it contains personal details, payment fields, and nonces required for form submission security. A cached checkout page served to the wrong user could expose billing addresses, contact details, and order contents. All pages under /my-account/ must be excluded as they contain sensitive customer data. The order confirmation page (/checkout/order-received/) must not be cached as it contains unique transaction details.
WooCommerce REST API endpoints under /wp-json/wc/ are dynamic, stateful, and often include authentication headers — do not cache these. Similarly, AJAX requests via /wp-admin/admin-ajax.php (used for adding items to cart, applying coupons, loading shipping rates) should never be cached. If you have pages using WooCommerce shortcodes on custom slugs rather than the default pages, you need to manually add those custom slugs to your exclusion list.
Cookie handling is critical to get right. QUIC.cloud and LSCache vary the cache based on cookies. The key cookies are wordpress_logged_in_* (bypass cache entirely), woocommerce_cart_hash and woocommerce_items_in_cart (bypass page cache), and wp_woocommerce_session_* (bypass page cache). The key risk is third-party plugins setting cookies that interfere — a plugin that sets a cookie on every page visit will effectively break your page cache for all users.
If your store uses a currency switcher or multilingual plugin, you need to vary the cache by currency or language. Configure this under LSCache → Cache → Cache Vary. Without this, a user who switches to EUR could receive a page cached in GBP with incorrect pricing displayed. See our guide on selling internationally for more on multi-currency performance.
Once your configuration is set, verify it methodically. Check cache headers on key pages using curl — a cached response will include an X-LiteSpeed-Cache: hit header. Verify cart and checkout bypass by adding a product and checking headers on /cart/ and /checkout/ — both should return bypass. Test as a logged-in user to confirm every page returns bypass. Monitor your QUIC.cloud dashboard for a CDN hit ratio above 70-80%. The safest collision test: open two browsers simultaneously, add a product in one, and confirm the other shows no cart state.
If you are using block-based cart and checkout, ensure that /wp-json/wc/store/ is explicitly excluded from caching. LSCache does not always detect these endpoints automatically. The block-based checkout behaves differently around nonces and session handling — test your checkout flow end-to-end after any caching configuration change.
QUIC.cloud’s deep integration with LiteSpeed Cache means the caching setup is more intelligent out of the box than what you would get from a generic CDN configuration. The problems tend to come from overrides — caching too aggressively, or from third-party plugins that break the cookie-based bypass logic. The principle: cache what is the same for every visitor, bypass what is unique to a session or user. That combination — fast for discovery, reliable for conversion — is what separates a well-tuned WooCommerce stack from one that is either slow or broken.
WP Pro Host runs LiteSpeed Enterprise with QUIC.cloud CDN on dedicated Ryzen hardware
Frequently Asked Questions
What is QUIC.cloud and how does it work with WooCommerce?
QUIC.cloud is a CDN built specifically for LiteSpeed Web Server. Unlike generic CDNs, it integrates directly with LiteSpeed Cache for WordPress (LSCWP), giving it application-level understanding of WordPress and WooCommerce. This means it knows which pages can be cached (product listings, category pages, homepage) and which must always be served dynamically (cart, checkout, account pages). QUIC.cloud also handles WooCommerce-aware cache invalidation — when a product stock level changes, it automatically purges the affected product and category pages from the CDN edge.
Which WooCommerce pages should be excluded from QUIC.cloud caching?
Pages that must never be served from CDN or server cache: cart (contains per-user basket data), checkout (payment flow with session-specific data), my-account and all its sub-pages (customer data), order confirmation pages, and any page using WooCommerce’s nonce-based security. Product pages and category pages can and should be cached for anonymous visitors. The LSCWP plugin handles these exclusions automatically when properly configured with WooCommerce integration enabled, but always verify the configuration by testing cart and checkout with an active session.
How does QUIC.cloud handle WooCommerce sessions?
QUIC.cloud uses cookie-based cache variation to detect WooCommerce sessions. When a visitor adds a product to their cart, WooCommerce sets a session cookie. QUIC.cloud detects this cookie and bypasses the cache for subsequent requests from that visitor, ensuring they see their actual cart state rather than a cached version. Anonymous visitors (no session cookie) receive cached responses. This split behaviour — cached for anonymous, dynamic for session users — is the correct WooCommerce caching model and is what QUIC.cloud handles natively through LSCWP integration.
Does QUIC.cloud improve WooCommerce performance for international customers?
Yes. QUIC.cloud has 30+ Points of Presence globally, serving static assets and cacheable page content from servers geographically close to the visitor. For a UK-hosted WooCommerce store serving international customers, CDN edge caching eliminates the round-trip latency to the UK origin server for static resources. A customer in Australia receives images, CSS, and JavaScript from a Sydney edge server rather than making a 17,000km round trip to London for every resource. Dynamic checkout requests still go to the origin, but static asset load time is dramatically reduced.
What is the difference between QUIC.cloud and Cloudflare for WooCommerce?
The key difference is application-level integration. Cloudflare treats WordPress and WooCommerce as generic HTTP applications — you must manually configure bypass rules for WooCommerce pages using cookies and URL patterns, and cache invalidation requires manual purging or custom API integrations. QUIC.cloud, through LSCWP integration, understands WooCommerce natively — it knows which pages contain dynamic WooCommerce content, handles cache invalidation automatically when products change, and supports Edge Side Includes (ESI) for partially caching pages that mix static and dynamic content. For WooCommerce on LiteSpeed hosting, QUIC.cloud is the more capable and lower-maintenance option.
Every plan includes full LSCache and QUIC.cloud CDN configuration support as standard.