Fragment Cache

Last edit: Mar 06, 2020

You can cache specific parts of a page or layout using fragment caching.
One common use case is to cache fragments that take a lot of time to fetch and/or render, for example a long-running GraphQL query.

Testing the cache

You can test the cache by adding a random string and 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.

views/pages/fragment-cache-simple.liquid


{% cache context.page.slug, expire: 10 %}
Random string: {{ 18 | random_string }}
{% endcache %}

Example

This example demonstrates rendering a lot of data (in this case generated inline, in real world, this would be fetched from the database):

views/pages/fragment-cache-long-running.liquid


Random string not cached: {{ 18 | random_string }} <br>

{% capture key %}{{ context.page.slug }}-v1{% endcapture %}
{% cache key, expire: 15 %}
  Random string cached: {{ 18 | random_string }} <br>
  {%- for i in (1..5000) -%}
    {%- assign r = 15 | random_string %}
    <span class="{{ r }}">{{ i }}</span>
  {%- endfor -%}
{% endcache %}

Authentication and Cross Site Request Forgery tokens

If you cache a fragment that includes a token (like an authenticity_token that's generated for a form request), 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 form Liquid tag.
If you're using JavaScript to submit forms, you can obtain the CSRF token for the current page from a cookie named CSRF-TOKEN.

Source code and demo

You can see the source code of this example on GitHub, and see a demo on our examples page.

Questions?

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