Title: Cache Vary Groups Behavior
Last modified: October 18, 2023

---

# Cache Vary Groups Behavior

 *  Resolved [featuremonkey](https://wordpress.org/support/users/featuremonkey/)
 * (@featuremonkey)
 * [2 years, 7 months ago](https://wordpress.org/support/topic/cache-vary-groups-behavior/)
 * Do LiteSpeed Cache Vary Groups work when ESI is not enabled?
    - [https://blog.litespeedtech.com/2017/09/13/wpw-vary-groups/](https://blog.litespeedtech.com/2017/09/13/wpw-vary-groups/)
 * How does **QUIC.cloud** serve these pages (without requesting the origin server)?
    - When cached Vary Group page is for guest user vs.
    - When cached Vary Group page is for a given role.

Viewing 9 replies - 1 through 9 (of 9 total)

 *  Plugin Support [qtwrk](https://wordpress.org/support/users/qtwrk/)
 * (@qtwrk)
 * [2 years, 7 months ago](https://wordpress.org/support/topic/cache-vary-groups-behavior/#post-17134547)
 * yes, it varies even without ESI , but when no ESI, every login users have its
   own private cache, so it doesn’t really impact on anything
 * for guest user , it is vary-group’ed as “guest” , which falls back to public 
   cache , when its login users , no matter what group this user belongs to , it
   has its own private cache.
 *  Thread Starter [featuremonkey](https://wordpress.org/support/users/featuremonkey/)
 * (@featuremonkey)
 * [2 years, 7 months ago](https://wordpress.org/support/topic/cache-vary-groups-behavior/#post-17137040)
 * Is the private cache served from the origin or QUIC.cloud CDN?
 * > when its login users , no matter what group this user belongs to , it has its
   > own private cache.
 * LightSpeed Cache states “When a page is privately-cached, there is a separate
   personalized copy stored for each user that requests it.”
    - [https://blog.litespeedtech.com/2017/08/30/wpw-private-cache-vs-public-cache/](https://blog.litespeedtech.com/2017/08/30/wpw-private-cache-vs-public-cache/)
 * Suppose that ESI is disabled and a cache vary is configured for three roles with
   1000 users.
    - Does this configuration store 1000 pages (one for each user) or does it store
      3 pages (one for each role) in addition to the public cache page.
 *  Plugin Support [qtwrk](https://wordpress.org/support/users/qtwrk/)
 * (@qtwrk)
 * [2 years, 7 months ago](https://wordpress.org/support/topic/cache-vary-groups-behavior/#post-17137047)
 * the cache is always generated from origin , and then it will be stored at QC 
   and origin
 * if you have 1000 users visited one page, then it will be 1000 cache objects in
   total , one per each, and this is the reason why private cache has shorter TTL
   to conserve disk space.
 *  Thread Starter [featuremonkey](https://wordpress.org/support/users/featuremonkey/)
 * (@featuremonkey)
 * [2 years, 7 months ago](https://wordpress.org/support/topic/cache-vary-groups-behavior/#post-17137086)
 * > the cache is always generated from origin , and then it will be stored at QC
   > and origin
 * So QC will perform authentication for logged-in user on private cache page to
   serve private cache page without hitting origin?
 * How do you configure QC to store 3 pages (one for each role) in addition to the
   public cache page?
 * You must enable ESI?
 * If I enable ESI, then it only stores a section of the page and always hits origin
   server for rest? Or does it store everything on QC, then create the template 
   in QC?
 *  Plugin Support [qtwrk](https://wordpress.org/support/users/qtwrk/)
 * (@qtwrk)
 * [2 years, 7 months ago](https://wordpress.org/support/topic/cache-vary-groups-behavior/#post-17137107)
 * the login status is stored in cookie , so QC will check the cookie value as authentication,
   if this private cache is stored on QC already , then no hit on origin , if it
   was not , or expired , then hit origin.
 * yes , you must enabled ESI
 * if you enable ESI , the page for login user , on same group , will have one “
   login-user’s public cache” , and utilize ESI block to fill in the rest
 * this pub cache , presumably will be stored on QC , but for ESI blocks , it will
   be same case as aforementioned private cache situation.
 * there is nothing special about QC , for functionaility-wise, it is literally 
   same as your origin’s LSCache engine , the only difference is the geolocation
   where the QC servers are placed , that is closer to end-users.
 *  Thread Starter [featuremonkey](https://wordpress.org/support/users/featuremonkey/)
 * (@featuremonkey)
 * [2 years, 7 months ago](https://wordpress.org/support/topic/cache-vary-groups-behavior/#post-17137243)
 * > the login status is stored in cookie , so QC will check the cookie value as
   > authentication , if this private cache is stored on QC already , then no hit
   > on origin , if it was not , or expired , then hit origin.
   >  qtwrk
 * This information contradicts what you said 2 months ago in this [forum post](https://wordpress.org/support/topic/membership-cache-configuration/).
 * > > How to perform authentication from the CDN level (without involving host 
   > > server)?
   > >  featuremonkey
   > well, this is NOT possible , CDN is only a reverse proxy server + caching ,
   > it does NOT carry any PHP script of your site.
   >  qtwrk
 * **Moving forward**, you have stated that the user must enable ESI to configure
   QC to store 3 pages (one for each role) in addition to the public cache page.
   However, the behavior you have provided does not match the behavior I am requesting.
 * > if you enable ESI , the page for login user , on same group , will have one“
   > login-user’s public cache” , and utilize ESI block to fill in the rest
   >  qtwrk
 * So with ESI enabled, there will be two objects on QC (after the origin is visited):
   Public and Private Cache. When a logged-in user visits the website, QC takes 
   the cookie to verify that user’s status, then takes the template private cache
   and fills it with an ESI block.
 * And that ESI block (e.g., headline for a logged-in role) is also stored on QC,
   so then QC doesn’t hit origin server to “fill” the page.
 * **Is that correct?**
 * If so, how do you configure QC to — instead of filling the template — just store
   3 page objects (one for each role), and serve those pages accordingly without
   hitting origin server?
 * > this pub cache , presumably will be stored on QC , but for ESI blocks , it 
   > will be same case as aforementioned private cache situation.
   >  qtwrtk
 * The public cache you refer to is the “Private Cache” of all logged-in users with
   ESI enabled. So, does this statement mean that
    1. ESI blocks will be cached per user (i.e 1000 esi cache block objects) on origin
       and QC?
    2. ESI Blocks will be cached per role (i.e 3 esi cache blocks objects) on origin
       and QC?
 *  Plugin Support [qtwrk](https://wordpress.org/support/users/qtwrk/)
 * (@qtwrk)
 * [2 years, 7 months ago](https://wordpress.org/support/topic/cache-vary-groups-behavior/#post-17137294)
 * there is no contradiction, but the term might be misunderstood here based on 
   the context.
 * the QC CDN is a proxy, by that saying, it only forwards traffic from one point
   to another, in this context , we are talking about browser and origin server,
   it does NOT execute the PHP code , and in the world of wordpress, the PHP code
   checks for user identity
 * in this case , the private cache is linked/tied to a cookie value.
 * once the origin server authenticated user, origin will instruct browser to store
   a cookie, and sent out page with cache instruction header, QC will store that
   cache, and later on, assuming this private cache is not expired/purged, then,
   when a browser sends request with that given cookie, the QC will provide this
   private cache
 * QC itself does not do the `authentication as check username/password against 
   database` , it checks/stores the result of `authentication by cookie`.
 * ——–
 * yes , just say you have a page , 90% of its content is same for all roles , only
   1 section, saying, a username-display, is private ESI block, then it will be (
   number of roles) public caches + (number of visited login users) private ESI 
   blocks.
 * once the cache is generated on origin, and during the proxy to user , the CDN
   node that proxies the traffic , will also store a copy regardless if it’s private
   or public , normal or ESI.
 * ——-
 * I am not exactly sure if I understand the question
 * ———
 * if it’s private ESI , it will be per user , otherwise per role.
 *  Thread Starter [featuremonkey](https://wordpress.org/support/users/featuremonkey/)
 * (@featuremonkey)
 * [2 years, 7 months ago](https://wordpress.org/support/topic/cache-vary-groups-behavior/#post-17137590)
 * > > If so, how do you configure QC to — instead of filling the template — just
   > > store 3 page objects (one for each role), and serve those pages accordingly
   > > without hitting origin server?
   > >  featuremonkey
   > I am not exactly sure if I understand the question
   >  qtwrk
 * Suppose that you have 3 + 1 roles:
    - Admin
    - Member A
    - Member B
    - (guest)
 * There is a page (with path /a-post ) with content that can be seen by both Admin
   and Member A, but not Member B or guest users.
 * When ESI is enabled, QC is still required to store lots of cache block objects
   for the page template (“public cache”; one for each role) and each user login(“
   private cache”; one for each logged-in user), then piece them together into a
   final page that is delivered to browser. However, this overhead is unnecessary
   in this scenario.
 * Instead, QC **could theoretically** generate 2 – 4 pages without ESI enabled 
   for less overhead:
    - Page (of path /a-post) output for Admin Role, Member A
    - Page (of path /a-post) output of Member B, guest
 * _*2 pages since the content has 2 variations; one for administrators and A members,
   one for B members or guests._
 * This theoretical setup only requires QC to store 2 pages (of path /a-post), instead
   of the discussed configurations where
    - ESI Disabled, Cache Vary Disabled: 1 “public” page for guests, with thousands
      of “private” DUPLICATED pages (one for each user).
    - ESI Disabled, Cache Vary Enabled: 4 useless “public” pages are created for
      each role, with thousands of “private” DUPLICATED pages (one for each user).
    - ESI Enabled, Cache Vary Enabled: 4 “public” pages are created for each role,
      with thousands of “private” DUPLICATED esi blocks for each user, which are
      then formatted into a final page upon request.
 * So instead of storing thousands of duplicated cache objects with those configurations,“
   how do you configure QC to only store the 2 – 4 final cache page objects (one
   for each role = 4; or one for users with the right cookie and one for users without
   the right cookie = 2)” for the same path (example /a-post), and serve the correct
   page object accordingly without hitting origin server?
 *  Plugin Support [qtwrk](https://wordpress.org/support/users/qtwrk/)
 * (@qtwrk)
 * [2 years, 7 months ago](https://wordpress.org/support/topic/cache-vary-groups-behavior/#post-17137742)
 * > Instead, QC **could theoretically** generate 2 – 4 pages without ESI enabled
   > for less overhead:
   >  - Page (of path /a-post) output for Admin Role, Member A
   >  - Page (of path /a-post) output of Member B, guest
 * yes, that’s very simplefied and optimal vision.
 * but how do you differentiate admin and member A in this case ? if use cookie ,
   you are invoking the cache vary , that will make page to serve individually and
   privately to admin and member A , then we are back to the previous situation 
   as a dead loop
 * or how do you detect member B and guest user ? in case to display login form,
   login link or something.
 * I mean , at certain point , you have to detect the user identify , like go to
   next/previous page , jump to account page …etc
 * and unfortunately you can’t , as plugin doesn’t work that way and what you asking
   is against plugin’s logic, or even wordpress’s logic.
 * > When ESI is enabled, QC is still required to store lots of cache block objects
 * in case there is a lot of ESI block , and the main point for ESI is to make cache
   as publicly as possible to reduce whole page process time when encounter private
   content , instead of re-generating the whole page , but only invoke PHP to generate
   a small section of it.
 * certainly you can modify the plugin source code to “overcome” this limitation
   and forcefully to make this happen , but that’s really out of support scope.

Viewing 9 replies - 1 through 9 (of 9 total)

The topic ‘Cache Vary Groups Behavior’ is closed to new replies.

 * ![](https://ps.w.org/litespeed-cache/assets/icon-256x256.png?rev=2554181)
 * [LiteSpeed Cache](https://wordpress.org/plugins/litespeed-cache/)
 * [Frequently Asked Questions](https://wordpress.org/plugins/litespeed-cache/#faq)
 * [Support Threads](https://wordpress.org/support/plugin/litespeed-cache/)
 * [Active Topics](https://wordpress.org/support/plugin/litespeed-cache/active/)
 * [Unresolved Topics](https://wordpress.org/support/plugin/litespeed-cache/unresolved/)
 * [Reviews](https://wordpress.org/support/plugin/litespeed-cache/reviews/)

## Tags

 * [cache](https://wordpress.org/support/topic-tag/cache/)
 * [esi](https://wordpress.org/support/topic-tag/esi/)
 * [vary](https://wordpress.org/support/topic-tag/vary/)

 * 9 replies
 * 2 participants
 * Last reply from: [qtwrk](https://wordpress.org/support/users/qtwrk/)
 * Last activity: [2 years, 7 months ago](https://wordpress.org/support/topic/cache-vary-groups-behavior/#post-17137742)
 * Status: resolved