What is Render Caching?
Have you ever found yourself asking the question “Why are my changes to my twig template not showing up?” or “Why do I have to clear my cache every time I make a change to a preprocess function?”. The answer is: Render Caching. Render caching is the process of storing post-rendered data so that Drupal does not needlessly rebuild and re-render arrays.
Why Render Cache?
The process of loading, rebuilding and re-rendering entities in Drupal is a very expensive task and much of the time, is unnecessary. Render caching allows us to bypass much of the unnecessary processing and dramatically improve the site performance.
So… What does the Render Cache look like?
The first step in your journey is to understand what makes up the Render Cache property:
- Cache Keys – a representation of a set of code that you want to make cacheable, and is typically something that is too expensive to render on every page load.
- Cache Contexts – variations of what I am rendering. Does my display change based on user role, language, time of day, location, etc?
- Cache Tags – custom identifiers that this render array depends on to render properly, such as Referenced Entity ID’s
- Cache max-age – determines how long the item I am rendering can be cached for. This should always be set.
The render cache is a “#cache” property that is defined on your render arrays. You are able to add and/or customize this for any render element.
Plan for caching
Working with render caching is something that you should be thinking about from the beginning of your project.
Some questions that may help you in the early stages of your project would be:
- How often are pages on my site updated?
- Are there any highly dynamic sections of the website? (ie. Stock Ticker, Countdown Timer, etc…)
- Is there any content that is context specific? (ie. Location based, user role based, etc…)
- Is the website complex enough to require custom render processing?
The importance of cache tags
Cache tags are where the magic happens! Cache tags allow the system to identify dependencies to a render object and invalidate pages when there are changes made to the dependent page.
As mentioned above, cache tags are custom identifiers that this render array depends on to render properly, such as Referenced Entity ID’s.
Real World Scenario:
Lets walk through an example: We have a website that has a blog post node/123: “My Drupal 8 Render Test” which is referenced in the recent content section on the home page, featured on a few of our product landing pages and in the related content of other blog pages.
In the example above, assuming that we have followed best practices and rendered our cache property arrays, the cache tag of “node:123” should have been added to the render tags array of the homepage, product landing pages and relevant blog posts that reference this item.
Now, we want to change the title of that page to be “Drupal 8 Render Caching”. When I save my node to make this update, it will trigger a cache invalidation of all nodes that have “node:123” in their cache tag list, thus ensuring that my new title shows up on pages where it is referenced.
For more advanced cache purging (memcache, varnish, CDNs), you will need to utilize the purge module. Acquia has recently launched their Public Beta for Acquia Purge as well, so if you are hosting on Acquia, it simplifies the process significantly.
There are more useful tidbits in the presentation that John Doyle, our CTO, gave at the DC Meetup in October.
Some additional community information around render caching:
- Disable Drupal 8 Render Caching for Development: https://www.drupal.org/node/2598914
- Drupal 8 Render Cache API: https://www.drupal.org/docs/8/api/render-api
- Cachability of Render Arrays: https://www.drupal.org/docs/8/api/render-api/cacheability-of-render-arrays