In a previous blog post, I explained the list cache tag for entity types, which you use when displaying a list of entities. This cache tag ensures that appropriate render caches and response caches are invalidated whenever a new entity is created, or an existing one is saved. One problem is that the {ENTITY_TYPE}_list cache tag is generic for all entities of that entity type. Invalidating it can cause a lot of cache churn for a large site with heavy activity.

What problem does a bundle-specific list cache tag solve?

Imagine a simplistic site with two content types: "Pages" (page) and "Blog posts" (blog_post.) We will also have the following assumptions:

• Pages are not created often but are updated periodically.
• Each page is linked individually from the main menu or other pieces of content.
• Blog posts are created often and generally not modified once created.
• On the /blog page, visitors can browse all the blog posts.

With this example, the /blog page will contain the node_list list cache tag within its cacheable metadata. The cache tag node_list will be part of its rendered output and bubble into the response's cacheable metadata.

The node_list cache tag will be invalidated whenever a blog post is saved. This ensures a newly published blog post shows up on the site, an unpublished one is removed, or changes to the content appear in the teaser appropriately. This is the expected behavior always to have correct output on the site's /blog page. This also happens whenever a page is updated. The node_list cache tag is invalidated whenever a page has been saved. That means the /blog page will have its relevant caches invalidated for irrelevant content changes! This is the problem the bundle-specific list cache tag solves.

In Drupal 8.9.0, a new cache tag pattern was added. The {ENTITY_TYPE}_list:{BUNDLE} cache tag was introduced (issue, change record) to help address the implications of using the list cache tag. Instead of only relying on node_list, we can use the node_list:page and node_list:blog_post cache tags. The /blog page can use node_list:blog_post instead of node_list and immediately perform better by gaining a higher cache hit ratio.

The caveat with the Views module

There is a 99% chance the /blog page was built using the Views module and not programmatically. The Views module still needs to optimize for the bundle-specific list cache tag. The generic list cache tag is always used. It is a complex issue as the displayed bundles must be computed from the configured filters on the view. You can read more about the current progress in this issue: Use new cache tag ENTITY_TYPE_list:BUNDLE in Views to improve cache hit rate.

There is a module that can be installed to solve this problem. The Views Custom Cache Tag module provides a new cache plugin to remove any list cache tags automatically added and allows specifying custom cache tags to associate with the view's output. We'd have to edit the /blog page view for the example site and specify the node_list:blog_post cache tag.

Unfortunately, this requires technical knowledge about this cache tag and the Views Custom Cache Tag module. If you are able and interested, solving the two issues above would remove this barrier.

Beyond bundles with list cache tags

Cache tags do not have to follow any specific pattern or paradigm; they only need to exist. Alex Pott opened an issue introducing a published variation of the list cache tag – node_list:published. The site's /blog page only shows published blog posts. Why should it be invalidated when draft blog posts are saved?

Joachim had great suggestions that could be used in Drupal Commerce storefronts. All products in a Drupal Commerce site are associated with a store. Drupal Commerce could provide a variation of commerce_product_list per store, such as commerce_product_list:store:{id}. If this cache tag existed and were used, the catalog listings between stores would have higher cache hit ratios!

Want to learn more about caching and Drupal?

I'm working on a book about Drupal's caching layers! Check out Understanding Drupal: A Complete Guide to Caching Layers.