Last edit: Dec 02, 2019
  • Contributors:
  • pavelloz
  • diana-lakatos

Static cache

Static cache means you create a static HTML site, and serve it bypassing the whole server side, including authorization.
It's super fast, but you can rarely use it. For example, it's great to use this for the home page, to make it very fast for non-authenticated users, but you can't do the same for a dashboard, because the user has to be authenticated.



  expire: 10 # static html page will be cached for 10 seconds

Dynamic cache

Dynamic cache works similarly to page caching, you can use it to cache the whole page, but the difference is that it triggers authorization, so it works also for logged in users.



  expire: 10 # keep the cache for 10 seconds
  layout: true # layout will be part of the cache, if it's not desired, use false instead
  key: > # by default the key is the whole url, for example If the page content does not depend on arguments, it's best to restrict it to just page.slug [ and/or context.params.slug2 etc ]
    {{ }}


The following properties control the action cache:


  • key - allows you to define a unique identifier for the page. By default, it's the full page URL. If you cache a page for 10 seconds, and the key is blank, cache will be generated for the whole URL. If the user changes anything in the URL, the cache will not be taken into consideration.
  • expire - if it is set to 0 and key is set, the cache will never expire by itself (updating the file would invalidate the cache though). If key is blank and expire is 0, the page won't be cached at all.
  • layout - makes layout part of the cached page. Default is false.

Using page caching, or action caching for the whole page, whenever you change something on the page and deploy it, the cache will be invalidated.
In reality, it's rarely possible to cache the whole page or layout (this is why layout is false by default).

Fragment cache

You can cache specific parts of a page or layout using fragment caching, where you just cache common parts, fragments that take a lot of time and can be cached, for example:

{% capture key %}{{ }}-v1{% endcapture %}
{% cache key, expire: 10 %}
   {% include 'partial_with_long_running_graphql_query' %}
   {% for ... %}
   {% endfor %}
{% endcache %}

Testing the cache

You can test the cache by adding a random string to the beginning of the page and another one to the beginning of the layout. This way, you can see if the string on the page or layout has changed after refreshing the page:

  • When the page is rendered from the cache, the string remains the same.
  • When the cache is invalidated (e.g. after the time specified in the expire property), the string changes.


randomstring: {{ 18 | random_string }}

Authentication and tokens

If you cache a whole page that includes a token (like an authenticity_token that's generated for each session), then the token gets also cached. This could, for example, prevent the user from submitting a form.

platformOS automatically processes the cache and updates those tokens if you use the platformOS-specific form tag.
If you'd like to use the form HTML tag, you have to include the token exactly as it is.
If you're using JavaScript, we include the CSRF token in the cookie of the logged in user.


We are always happy to help with any questions you may have.