The first thing I would like to mention before getting into the meat of the Cache API is that this subsystem is one of the best documented ones (at the time of writing). You can check out the main entry page (https://www.drupal.org/docs/8/api/cache-api/cache-api) and I recommend keeping it close by when developing.

The Cache system in Drupal 8 provides the API needed to handle the creation, storage, and invalidation of cached data. From a storage perspective, it is extensible, allowing us to write our own custom cache backends (CacheBackendInterface). By default, however, cache data gets stored in the database and hence the default backend is DatabaseBackend. Going forward, we will focus only on this implementation since it is the most commonly used one, especially when starting a new project. Quite often though, once the site becomes more complex, alternative caching backends can be employed for better performance—such as Memecache or Redis.

The simplest type of cache in Drupal 8 is the so-called Internal Page Cache, whose functionality resides inside the Page Cache core module. The goal of this cache layer is to serve anonymous users with responses that are cached in their entirety. The primary assumption is that certain pages can be cached once and served to all anonymous users just the same—an approach similar to what we had in Drupal 7. Unlike the previous version though, this one is much smarter when it comes to (not) serving stale content as it makes use of the so-called cache tags to invalidate cached pages when something on those page changes. We will talk about cache tags in more detail soon.

This module is enabled by default when installing Drupal 8 and can be configured more or less the same as in Drupal 7 by going to admin/config/development/performance:

Although serving anonymous users in not-so-complex websites was not that bad in Drupal 7, when it came to authenticated users it was quite the opposite. The contributed Authcache module was the best solution for dynamic and granular caching, but it was extremely difficult to use and implement. Some of its core tenets, however, have been used in the development of the Dynamic Page Cache module in Drupal 8, which makes things much simpler (and robust).

This core module also comes enabled by default and provides all the necessaries for caching pages for all kinds of users. That is, pages that can depend on certain cache contexts. In a nutshell, the approach of this module is to cache together the bits of the page that can be served for all users and handle the dynamic content that depends on a context separately. It can do so because of the standardization of those bits into render arrays and other components that can provide cacheability metadata. The latter is collected and used to cache and invalidate the final result. We will talk about cache contexts and all this metadata in this chapter and get a better understanding of it.

Before continuing, I recommend you look back to the Developer settings section of Chapter 1, Developing for Drupal 8, where I recommended that you use the developer settings when doing development. One of the reasons is caching, primarily the dynamic page cache, which you can disable inside the settings.php file:

$settings['cache']['bins']['dynamic_page_cache'] = 'cache.backend.null';  

It is difficult to do actual development with caching enabled, but at the same time, it's important to often enable it and make sure your code still runs correctly. It is very easy to forget about certain bits of code that depend on a context or should be invalidated upon an action, and sometimes you will only spot these if you test with caching enabled.

That being said, let's talk about cacheability metadata and how this works with render arrays.