Performance Optimizations: benefits ​

Magento varies every cached page by customer group and login state. A store with five customer groups therefore caches five copies of each category page, and a logged-in shopper often gets a cache miss on a page a guest already warmed. This extension removes that split and restores per-group prices over AJAX afterwards.

Key business benefits ​

• One cache entry per page instead of one per customer group - Cache storage drops by roughly a factor of the number of active groups. The pages a guest warms are the same ones a logged-in customer hits.
• Logged-in shoppers get warm pages - Login state no longer changes the cache key, so signing in stops throwing away every cached page for that visitor.
• Faster cache warming - A crawler or a warmup job covers the catalog once rather than once per group. This matters most right after a deployment or a full cache flush.
• B2B stores benefit most - Group-based pricing is what fragments the cache. A store with a dozen trade groups caches a dozen copies of every catalog page.
• Prices stay correct per group - Catalog prices, and the layered navigation price slider bounds, are re-fetched for the shopper's real customer group after the page loads.
• Cache fragmentation becomes measurable - The vary tracking grid records each distinct X-Magento-Vary value with the HTTP context that produced it, so an unexpected split can be traced to the context key causing it.

Example use cases ​

• A B2B store on a shared hosting budget - Consolidating the cache is cheaper than sizing Varnish for group-multiplied storage.
• Diagnosing a poor hit rate - Turn on vary tracking alone, browse the store, and read which context keys are producing distinct hashes. This works without enabling unified vary at all.
• A catalog too large to warm per group - Where a full warmup already takes hours, one pass over the catalog replaces one pass per group.

What to weigh first ​

Unified vary has costs attached.

• Until the AJAX request returns, the shopper sees the cached guest price. On a store where group prices differ noticeably, that flash is visible.
• Guest price rendering is forced on five page types only. Any other page rendering catalog prices needs checking before this goes live.
• Price-sorted and price-filtered listings opt out per request and stay cached per group, and that detection reads the URL only.

The overview page lists the full set of limits under Cache correctness limits. Read it before enabling unified vary on a production store.