Caching in Drupal provides faster page loads and saves server resources. It uses cache backends like the database to store cached content in bins like page or block caches. Cache tags and contexts allow invalidating specific cached content when the underlying data changes. The cache API allows developers to specify cacheability metadata to effectively cache parts of pages, while ensuring cached content remains valid.

1. Caching in Drupal
Presented by-
Vivek Panicker
Software Developer
Innoraft

2. Why do we need caching?
● To get faster response times
● To save server resources
● To save money

3. Quote
"There are only two hard things in Computer Science: cache
invalidation and naming things."

4. Drupal Cache storage

5. Cache backend
● This is the actual physical storage space for cache data.
● OOTB, Drupal stores cache data in the database.
● Drupal provides us with the option to configure different backends if required
for different types of caches (bins).
● For eg. the contrib module memcache provides the ability to use memcache
as the cache backend.
● OOTB, Drupal provides other backends in core like PhpBackend,
MemoryBackend, NullBackend, ChainedFastBackend of which
ChainedFastBackend is the most interesting as it helps us to combine two
cache backends (fast and slow) together.

6. Cache bin
● These are logical partitions of cached data.
● It is useful for
○ Logically segregating cache data based on type of cached content.
○ Faster retrieval of cached data - if the database is used as cache and all
cache data is stored in a single table, then time for retrieval of data would
increase with increase in the size of the table.
● OOTB, Drupal creates bins for storing bootstrap, config, container, render,
page, dynamic page etc caches and each of them has a separate database
table.
● Developers can easily provide a custom cache bin by just simply creating a
service definition.

7. Page level caching

8. ● This is Drupal’s Built-in reverse proxy server.
● Stores the final prepared complete HTML response.
● This is used for anonymous user caching.
● A page cache entry gets invalidated as soon as any of it’s cache tags is
invalidated thus showing instantaneous page updates.
● Only the cache entries whose tags are invalidated are marked as invalid,
which is different from Drupal 7 where the entire page cache was invalidated.
● We can determine the cacheability metadata for a page by looking at the X-
Drupal-Cache-Tags and the X-Drupal-Cache-Contexts headers in the
response.
Page Cache

9. Dynamic Page Cache
● Page cache only caches for anonymous users.
● Dynamic page cache can cache for authenticated users.
● As authenticated users have a lot of personalized content, those parts of the
page which display those personalized content are replaced with
placeholders before being stored in the cache (a process called as auto-
placeholdering).
● When such a cached page is accessed, the cached data is fetched, the
placeholders are replaced with the actual content.
● As a result it is slower than page cache (which caches the complete
response) but still it makes accessing pages faster for authenticated users.

10. Source: https://wimleers.com/talk/rendering-caching-journey-layers

11. Cache API

12. Cache API
● Drupal allows developers to provide cacheability metadata for the cacheable
elements.
● This can be done mainly with the help of the following
○ Tags
○ Contexts
○ Max-age

13. Cache tags
● The data that we want to cache, is it aggregated from some other sources of
data like config, node?
● If yes, then we need to specify the data sources as dependencies, so that if
the data in any of the source changes, then our cached entity should be
marked as being stale i.e. invalid.
● The dependencies are specified in the form of cache tags.
● Cache tags are an array of strings mentioned as [‘thing:identifier’,
‘thing:identifier’, …..], where thing can be node/config/user/taxonomy_term
etc.
● There are also list cache tags, eg. node_list which gets invalidated when any
new node is added/removed.

14. Cache tags
● Eg. if the cached data depends on the data of node/5 and the system.site
configuration, then we have to specify the cache tags as [‘node:5’,
‘config:system.site’].
● Cache tags are invalidated across all cache bins.
● CDNs support using cache tags - eg. Fastly, CloudFlare, which is great!
● Varnish also supports cache tags.
● Contrib module like Purge can be used flush the reverse proxy servers/CDN.

15. Cache contexts
● The data that we want to cache, does it vary, i.e. have different
representations based on different factors?
● For eg. for different languages, the same data will have different translations.
● Since the data has different representations based on context, we have to
provide those contexts in the form of cache contexts.
● Cache Contexts are provided as an array of strings, eg: [‘language’, ‘url’] will be
the cache contexts for data varying by language OR URL.
● Each variation of the data is cached separately and is fetched based on the
context.

16. Cache Max-age
● The data that we want to cache, how long is it valid? Is there a fixed time?
● If yes, then we need to mention the time(in seconds) for it’s max-age.
● Usually this is not used for data that can be cached, since it usually is
invalidated by its cache tags.
● Max-age=0 , signifies that the data is not cacheable at all!
● At present there are some issues with max-age=0 being set for anonymous
user content, so we should use it with caution.

17. Bubbleability of Cache data
● Imagine a bottle of soda, where a bubble moves from the bottom to the top
and disrupts the surface of the soda.
● Similarly, cache metadata defined for the smallest render array of a page,
becomes part of the cache metadata of the entire page!
● Why?
○ Suppose there is a link in a page, which points to the current logged in user profile and
provides the user cache context in the render array..
○ When the entire page is cached, the system should know that it contains something that is
related to the current user.
So that when a different user views that page, the system does not end up showing the same
page from the cache which was shown to the previous user.
● Cache tags, contexts and max-age all bubble up to the page level cache.

18. Response headers
● In services.yml, we need to enable response headers debugging.
● After doing that, we start receiving X-Drupal-Cache-Tags and X-Drupal-Cache-
Contexts headers in the response.
● This contains the list of all the cache tags and cache contexts that the
response is dependant on.
● This is very useful for debugging cache related issues.

19. Additional points about Cache API
● Use with caution, as incorrect usage can cause potential security issue or
incorrect data being shown to the user!
Eg. not using user cache context on a block that shows the logged in user’s
name.
● Like all other awesome things in Drupal, Cache API provisions can be
extended for our custom usage.
● Eg. the contrib module memcache provides it own cache backend.

20. THANK YOU!!!