Client-side post-hydration fetch vs short-TTL edge caching for Vue Storefront mini-cart counters on cacheable catalog pages

Direct answer

For personalized fragments such as mini-cart counters, wishlist totals, or group pricing on otherwise cacheable catalog pages, client-side post-hydration fetching is the approach that better matches documented Vue Storefront and Alokai caching behavior. Short-TTL edge caching of full pages that contain private data is generally discouraged because it forces session-aware cache keys or Vary headers that erode CDN hit rates and create leakage risk.

Why short-TTL edge caching is a poor fit for private fragments

When a mini-cart counter is embedded in cached HTML, the CDN must distinguish every shopper. Adding a session or cart identifier to the cache key turns a shared asset into a per-user object, which defeats the purpose of edge caching and can degrade cache efficiency. Even with a short TTL, the window between cache writes is enough for one anonymous session to receive another session's fragment if key scoping is imperfect. The safer boundary is to keep private data out of shared caches entirely and let the catalog shell remain globally cacheable.

Confirmed behavior vs. version-sensitive assumptions

It is well established that anonymous catalog, category, and product pages are intended to be cached at the CDN and server layers, while cart, checkout, and customer routes are excluded from shared caches. It is also a common architectural pattern to hydrate private fragments client-side so the cached HTML stays generic. What is less certain without checking your installed version is how the SSR layer initializes private state: older Vue Storefront releases and newer Alokai middleware differ in whether a server-side aggregation step already attempts to inline cart data, and whether that data is properly stripped before caching. Treat the exact hydration boundary as version-sensitive and verify it in staging.

Scoping cache keys and route exclusions

1. Exclude private routes. Ensure cart, checkout, account, and any API endpoints that return customer-specific data are marked no-store or bypassed at the CDN and Redis layers.
2. Scope catalog keys narrowly. For cacheable pages, include only store, currency, locale, and—if you run B2B group pricing—customer-group or price-list identifiers. Do not include session IDs.
3. Fetch private fragments after hydration. Use a client-only composable or effect to call the cart/wishlist API once the app is hydrated. The endpoint should return Cache-Control: private, no-store.
4. Reserve layout space. Render a skeleton or placeholder for the counter so the post-hydration update does not cause layout shift.

Practical verification

• Open browser devtools and confirm the mini-cart request is a separate XHR/fetch after the main document loads.
• Inspect response headers: the catalog page should show a CDN HIT (e.g., X-Cache: HIT), while the cart API shows BYPASS or MISS.
• Load the same catalog URL in two different browser profiles and verify the mini-cart counters remain independent.

One diagnostic that changes the recommendation

Which Vue Storefront or Alokai version and server middleware are you running? If your release already inlines cart state during SSR and strips it before caching, you may only need to disable that inlining and add a client fetch. If it does not, the wiring effort is higher and the short-TTL temptation is stronger—but still not advisable for shared caches.