ESI for WooCommerce
WooCommerce adds per-user state (cart contents, account links, nonces) that can reduce your page-cache hit rate. ESI (Edge Side Includes) is a pattern that lets you cache most of the page while rendering a small fragment dynamically.
When You Need ESI
Consider ESI when:
- Public product/category pages are not caching because cart cookies force bypass
- You want cached pages, but still need a live mini-cart count or user-specific widget
Prerequisites
ESI requires an ESI-capable caching layer. In the WordPress ecosystem this is commonly LiteSpeed Enterprise + LSCache.
note
If you are on OpenLiteSpeed or Nginx without an ESI solution, you can still get most benefits by caching public pages and bypassing cart/checkout/account routes.
What to Put Behind ESI
Good ESI candidates are small, frequently changing, per-user fragments:
- Mini-cart/cart count
- Logged-in greeting/account widget
- Wishlist count (if it changes per user)
Avoid making large parts of the page ESI (it reduces the benefit of caching).
Verification
- Confirm the page itself is cached for guests.
- Confirm the ESI fragment updates per session.
- Test two separate sessions (incognito windows) and verify cart counts do not leak.
Header signal (LiteSpeed example):
curl-check-esi-header.sh
curl -I https://example.com/shop/ | grep -i x-litespeed-cache-control
Example output:
litespeed-esi-on.txt
x-litespeed-cache-control: esi=on
Common Pitfalls
| Pitfall | Risk | Fix |
|---|---|---|
| Treating per-user fragments as public | Data leakage / wrong cart counts | Use private ESI for per-user content |
| Purging everything on cart events | Low hit rate | Purge selectively and keep ESI fragments small |
| Caching cart/checkout pages | Broken checkout | Exclude /cart, /checkout, /my-account |