WooCommerce performance Case study
A2 MU Fullpage Microcache
Product pages were spending most of their time being rebuilt by Elementor and the database for visitors who would all have received the same HTML. This is the cache that stopped that, drawn tightly enough around anonymous traffic that a logged-in customer never touches it.
The business problem
Product detail pages needed lower TTFB without unsafe caching of carts, logged-in sessions or checkout states.
What I delivered
- Guest-only disk-based HTML microcache for PDP and shop paths.
- Invalidation rules tied to product updates, Elementor changes and commerce events.
- A safer cache boundary around anonymous product browsing.
Technical approach
- Excluded personalized and transactional states from microcache.
- Kept invalidation explicit so stale product pages could be controlled.
- Measured the PDP path before and after release.
Result and evidence
Product detail page TTFB was reduced from approximately 2.3s to 0.9s in the measured production path.
Commercial value
The work improved the buyer-facing experience while preserving the safety boundaries a WooCommerce store needs.
Delivery notes
My role was to define the safe boundary, connect the fix to daily store operations and keep A2 MU Fullpage Microcache maintainable after release.
- Defined the safe boundary before changing behaviour.
- Kept the implementation understandable for future maintenance.
- Connected the technical work to an outcome the team could use.
Readable implementation brief
implementation_brief {
project: "A2 MU Fullpage Microcache"
context: "WooCommerce performance"
problem: "Product detail pages needed lower TTFB without unsafe caching of carts, logged-in sessions or checkout states."
delivered: "Guest-only disk-based HTML microcache for PDP and shop paths.; Invalidation rules tied to product updates, Elementor changes and commerce ev"
evidence: "Product detail page TTFB was reduced from approximately 2.3s to 0.9s in the measured production path."
value: "The work improved the buyer-facing experience while preserving the safety boundaries a WooCommerce store needs."
}What this project shows
Every interesting decision in a commerce cache is about what not to cache. Guest-only, path-scoped, and invalidated on the events that actually change the output.
I would rather have a cache with a narrow, provable boundary than a faster one I have to reason about every time somebody reports a wrong price.