Cache

Last edit:  Jan 12, 2019

Contributors:  diana-lakatos Slashek

Page caching

Page caching 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.

Example:

views/pages/home.liquid:


---
slug: /
static_cache:
  expire: 10 # static html page will be cached for 10 seconds
---
...

Action caching

Action caching 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.

Example:

views/pages/home.liquid:


---
slug: /
dynamic_cache:
  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 https://example.com?my_arg=1. 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 ]
    {{ context.page.slug }}
---
...

Explanation:

The following properties control the action cache:


dynamic_cache:
  key:
  layout:
  expire:

  • 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 cache_expiration_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.
  • If expire 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.
  • The default for layout is false.

Fragment caching

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).

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:


{% assign key = context.page.slug %}
{% cache key, expire: 5 %}
   {% include 'very_big_graph_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.

Example:


randomstring: {{ 18 | random_string }}

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.

Questions?

We are always happy to help with any questions you may have. Check out our Help page, or contact us.