HST Page Caching (Context Aware Cache) - Bloomreach Experience - Open Source CMS

This article covers a Hippo CMS version 10. There's an updated version available that covers our most recent release.


HST Page Caching (Context Aware Cache)

The HST includes a page cache valve. Its primary focus is:

  1. Make sure hot spot pages can frequently be served from cache.
  2. Make sure stampeding herds are less harmful because the page cache is blocking : Only a single request for a single page cachekey will be processed concurrently. All concurrent requests for the exact same page will be blocked and served a rendered response by a single request.

The cache works well for personalized sites as well, for example through targeting.

Serving 20.000+ pages per second

The HST page cache serves more than 20.000 pages per second once a page is cached. This is an enormous throughput, certainly if you realize that for a request that has a cached response, the HST still does:


  1. Host, mount and sitemap item matching.
  2. Look up the component configuration and checks whether the component tree is cacheable.
  3. Executes all the initialization valves, all the processing valves until the  pageCachingValve, and all the clean up valves.


Because the HST design scales very well up and out, page caching can serve such a large throughput while still doing all the processing mentioned above.

Seamless integrated with personalized pages

When using Hippo Relevance to support personalized pages, the page cache works as well because the computed profile for the visitor in included in the cache key.


By default, page caching is disabled. Caching is always disabled for


  1. action URLs
  2. preview sites 
  3. sites in cms channel manager / template composer  
  4. requests that are processed with subjectbasedsession

The caching valve is currently only included in the DefaultSitePipeline, so currently not for jaxrs pipelines. Caching for normal live sites can be switched on and off on different levels of HST configuration. It can be switched on/off per: 

  1. Hosts, Host, Mount or SitemapItem configuration. 
  2. HST  component configuration

 A rendered response is only cacheable if and only if the matched sitemap item is cacheable and the root component that the matched sitemap item points to is cacheable.

Cacheable configuration on Hosts, Host, Mount and SitemapItem level

To turn on caching globally for everything, you can set on hst:hosts the property hst:cacheable=true. Every hst:host, sub host, mount, sub mount and sitemap items now inherits this property. When not configured on hst:hosts, caching is false. Every host, sub host, mount, sub mount or sitemap item can override this  cacheable property. Everything below the item that did override the value, inherits the overridden value.

For example, assume your configuration looks like:

+ hst:hosts
   -hst:cacheable = false
   + dev
      + localhost
      |   - hst:cacheable = true
      |   + hst:root
      |       + nl
      |       - hst:cacheable = false
          + hst:root
              + nl
              - hst:cacheable = true

In this example, both  localhost/hst:root and have caching set to  true

In a sitemap, all items are by default cacheable or not depending on the hst:mount. If the mount is cacheable, then the sitemap is cacheable by default.

For example, assume the mount has hst:cacheable = true, and the sitemap looks as follows:

   + home
   + news
       + *
          - hst:cacheable = false
          + *
             + **.html
                -hst:cacheable = true

Then the items home, news and news/*/*/**.html are  cacheable, and the items news/* and news/*/* are uncacheable.

Cacheable configuration on HST component configuration 

By default, every hst:component is  cacheable. When an hst:component needs to be uncacheable, you can indicate this through hst:cacheable=false.

A composite tree of HST components is only  cacheable if every HST component in the composite structure of components that will be rendered during the request is  cacheable

Note that the above thus excludes HST components that are marked as hst:async=true, as those components are not rendered during the request. Also see async rendering. Using async can thus be very useful for rendering uncacheable components. However realize that async components  cannot contribute to hst headContributions (for example the title of the page or some javascript to be added in the head or at the bottom of the html)

async component cannot contribute to HST  headContributions

Marking pages during rendering as uncacheable

There are two situations through which a page that is marked as cacheable by the sitemap item and/or hst component but that the page in the end still won't be cached:


  1. Setting one or more non-caching header : If a developer puts during rendering ( HstComponent / jsp / ftl) to the response a Pragma no-cache, or a Cache-Control no-cache or an expires of 0 or lower, the rendered response won't be cached
  2. Setting cookies on the response : If a developer sets during rendering ( HstComponent / jsp / ftl) sets cookies on the response, the rendered response won't be cached. Note that cookies set by the HST framework won't influence caching. Also note that HttpSession cookies do not influence caching. If you create a HttpSession as developer and the page cannot be cached, you should either set a non-caching header or mark the hst component as uncacheable.
Did you find this page helpful?
How could this documentation serve you better?
On this page
    Did you find this page helpful?
    How could this documentation serve you better?