WooCommerce performance Case study
A2 MU Fullpage Microcache
Elementor and the database rebuilt every product page from scratch, even though every anonymous visitor got the same HTML back. I built a cache to stop that, drawn tightly enough around anonymous traffic that a logged-in customer never touches it, and then built the controls that let a team purge, rebuild and warm it without a developer on call.
The business problem
Product detail pages needed lower TTFB, and I could not get it by caching carts, logged-in sessions or checkout states. A cache only I could rebuild would have been the second problem: as soon as product updates, layout edits or checkout traffic are in play, operating it by hand is its own risk.
What I delivered
- A guest-only disk-based HTML microcache for PDP and shop paths, time-bounded so an entry expires on its own even when an invalidation is missed.
- Invalidation rules tied to product updates, Elementor changes and commerce events.
- Bypass-first rules that keep cart, checkout, account, order-pay, AJAX, POST and logged-in requests out of the cache entirely.
- Admin controls for purging, reviewing and rebuilding the cache, behind capability checks, so maintenance never needs shell access.
- Batch rebuild and a warm worker that runs in bounded units instead of one long request that piles up on the server.
Technical approach
- I classified the request before touching the cache: any unsafe commerce state takes the normal WooCommerce path, and only a guest product or archive view can hit or fill an entry.
- I made invalidation explicit, so I can control when a product page goes stale, and paired it with a TTL as the safety net.
- I kept the operation tools off the public page-serving path and split rebuilds into fixed-size batches, so warming never becomes a new spike.
- I measured the PDP path before and after release, and published the architecture while keeping cache paths, keys and live rules private.
Result and evidence
In the measured production path, product detail page TTFB fell from approximately 2.3s to 0.9s. The cache is also easier to operate and safer to recover: a purge, a rebuild or a rollback is a bounded, reviewable action, and none of the live cache internals had to be published to show it.
Commercial value
Buyers get a faster product page, the store keeps the safety boundaries WooCommerce needs, and performance work becomes repeatable: after a product or layout change the team can recover the cache themselves instead of waiting on a developer.
Delivery notes
I defined the safe boundary, tied the fix to how the store runs day to day, and turned a performance mechanism into something a team can control, verify and roll back.
- I drew the safe boundary before I changed any behaviour.
- I built for recoverability, not a one-off speed gain.
- I kept the implementation easy to follow for whoever maintains it next, and kept the production evidence and live rules private.
Readable implementation brief
implementation_brief {
project: "A2 MU Fullpage Microcache"
context: "WooCommerce performance"
problem: "Product detail pages needed lower TTFB, without caching carts, logged-in sessions or checkout states."
delivered: "Guest-only, time-bounded disk microcache for PDP and shop paths; explicit invalidation on product, Elementor and commerce events."
operations: "Admin purge and rebuild controls behind capability checks; batch rebuild; bounded warm worker."
bypass: "cart, checkout, account, order-pay, AJAX, POST, logged-in"
private: "cache keys, paths, live rules, logs"
evidence: "In the measured production path, product detail page TTFB fell from approximately 2.3s to 0.9s."
value: "Buyers get a faster product page, and the store keeps the safety boundaries WooCommerce needs."
}What this project shows
In a commerce cache, every interesting decision is about what not to cache. This one stays guest-only and path-scoped, it clears on the events that actually change the output, and it expires on its own when an event is missed.
Anyone can add a cache; the work is the controls that let a team run it safely. I would rather have a cache with a narrow, provable boundary and an admin-side purge than a faster one I have to reason about every time somebody reports a wrong price.