Vue Storefront is now Alokai! Learn More
Caching rules

Caching rules

The documentation only applies to instances deployed on Alokai@Edge.

CDN is not available when Basic Auth is enabled, since authentication headers prevent efficient caching.

The CDN caches Storefront application responses according to your caching rules. Learn more about Making SSR cacheable.


General behavior

  • These rules have no effect when the CDN is disabled, and invalidation won’t run. You can still add, edit, and delete entries while CDN is off (useful for staging config).
  • Invalidation is required for changes to take effect in cache and typically takes a few minutes.

Query parameters

URL parameters can be included or excluded from the cache key to either cache multiple variants of the same page (e.g., by lang or currency) or ignore noisy parameters such as utm_* so they don’t fragment the cache.

Control how query parameters affect CDN caching by using an allow list or a deny list.

  • Only parameters in the allow list are included in the cache key.
  • Parameters in the deny list are excluded from the cache key.
  • Requests that differ only by ignored parameters will reuse the same cached response.

Steps

  • Pick one mode: allow (include only listed params) or deny (exclude listed params). You cannot run both at once.
  • Lists are disabled by default and cannot be enabled when empty.
  • After add/edit, trigger cache invalidation; without it the cache key won’t change (no visible effect). Invalidation may take a few minutes.
  • You may prepare lists while disabled; invalidation still works on updates (if CDN is enabled).

Notes

  • Use allow list when you know a small, stable set of meaningful params (e.g., lang, currency).
  • Use deny list to strip noise families (e.g., utm_*, gclid, fbclid) when the meaningful set is large or variable.

Examples

  • Deny list: utm_source, utm_medium, utm_campaign, gclid, fbclid
  • Allow list: lang, currency

Named cookies

A small set of cookies (e.g., locale, logged_in) may be used to influence caching and serve different variants for different user groups.

Using cookies in the cache key is risky, as most have unique values per user. This leads to cache fragmentation, low hit ratio, and potential leakage of personalized content.

Control how cookies affect CDN caching by providing a list of cookie names:

  • Only cookies in this list are included in the cache key.
  • All other cookies are ignored.
  • Requests that differ only by ignored cookies will reuse the same cached response.

Steps

  • Enable the feature, then add cookie names that should affect the cache key (e.g., locale, or a low-cardinality auth flag).
  • An empty list cannot be enabled.
  • On add/edit, trigger cache invalidation; skipping it leaves existing cache unchanged. Invalidation may take a few minutes.
  • You may prepare lists while disabled; invalidation still works on updates (if CDN is enabled).

Notes

  • Prefer low-cardinality cookies such as: logged_in (boolean), role (few values), locale (limited set), ab_bucket (A/B test buckets).
  • Names can include alphanumeric characters (a-z, A-Z, 0-9) and the special characters - and _. Additionally, name must not start or end with - or _.

Examples

  • Good: locale, logged_in, ab_bucket
  • Risky (high cardinality): session_id, cart_id

Named headers

Specific HTTP headers (e.g., Accept-Language, X-Device-Class) can define cache variations to ensure the right content is delivered for a user’s language or device type.

Varying by raw User-Agent creates extremely high cardinality and may tank cache efficiency.

Control how specific HTTP headers affect CDN caching by providing a list of header names.

  • Only headers in this list are included in the cache key.
  • All other headers are ignored.
  • Requests that differ only by ignored headers will reuse the same cached response.

Steps

  • Enable the feature and add header names (e.g., Accept-Language).
  • An empty list cannot be enabled.
  • On add/edit, trigger cache invalidation; skipping it leaves existing cache unchanged. Invalidation may take a few minutes.
  • You may prepare lists while disabled; invalidation still works on updates (if CDN is enabled).

Notes

  • If you need device-based variation, consider using a normalized header your edge/origin sets (e.g., X-Device-Class: mobile|desktop|tablet) instead of raw User-Agent.
  • Names can include alphanumeric characters (a-z, A-Z, 0-9) and the special characters - and _. Additionally, name must not start or end with - or _.

Examples

  • Language: Accept-Language
  • Device class (normalized/custom): X-Device-Class
  • Avoid: User-Agent (too many unique values)