Enabling Views caching (time-based or tag-based)for Drupal 11 , 10 , 9 , and 8

Home » Performance Optimization » Enabling Views caching (time-based or tag-based)
Last updated :  
11.x , 10.x , 9.x , 8.x

A View that queries the database on every single page load is like a barista who re-brews a fresh pot of coffee for every customer, even when the same ten regulars order the same drink every five minutes. Views caching is the thermos: brew once, pour from the thermos for everyone else until it's actually time for a fresh batch. This lesson covers the two caching strategies Views ships with out of the box, and how to pick between them.

What you'll learn in this lesson

  • The two built-in Views cache plugins: time-based and tag-based, and how they differ
  • How to enable either one from the View's own Advanced settings — no code required
  • Why tag-based caching is almost always the better default on a modern Drupal 10/11 site
  • A genuine gotcha with time-based caching that catches people off guard

Time-based caching: simple, but blunt

Time-based caching, backed by \Drupal\views\Plugin\views\cache\Time, stores the View's rendered output (or just its query results, depending on the setting) for a fixed number of seconds you choose. Enable it from Structure → Views → [your view] → Advanced → Caching → Time-based, and set a "Results" lifespan (how long the query results stay cached) and an "Output" lifespan (how long the rendered HTML stays cached).

The appeal is obvious: set it to 300 seconds and you've just cut your database load for that View by roughly 300x under steady traffic, no code required. The catch is right there in the name — it's purely time-driven. If someone publishes a new article that this View is supposed to show immediately, it won't appear until the cache lifespan expires, no matter what actually changed on the site.

Tag-based caching: smarter invalidation

Tag-based caching, backed by \Drupal\views\Plugin\views\cache\Tag, takes a fundamentally different approach: instead of expiring on a timer, it expires the instant something the View actually depends on changes. Drupal's render pipeline automatically attaches cache tags like node_list or node:42 to a View's output based on what it queries, and the View's cached copy is invalidated the moment any of those tags are invalidated elsewhere on the site — for example, when an editor saves a node.

Why this matters: tag-based caching gives you both correctness and performance at the same time — content updates appear immediately, but nothing gets re-queried until something real actually changes. There's no lifespan number to guess at, no stale-content window to worry about. This is why it's the sensible default for almost every View on a modern site; reach for time-based caching only when a View depends on something Drupal's cache tag system genuinely can't track (a third-party API response, for instance).

Enabling it, step by step

  1. Navigate to Structure → Views and open the View you want to cache.
  2. In the View editor, find Advanced in the right-hand column and click Caching (it shows "None" by default).
  3. Choose Tag based (or Time based if you have a specific reason to) and save.
  4. Save the View itself to apply the change.

Quick check: you set a View to time-based caching with a 1-hour output lifespan. An editor publishes an urgent correction to an article this View displays. How long until visitors see the correction? (Up to a full hour — time-based caching has no way to know the content changed; it only knows the clock. This is exactly the scenario tag-based caching solves.)

Key takeaways

  • Views ships with two cache plugins: Time (a fixed lifespan) and Tag (invalidated by real cache tags like node_list).
  • Tag-based caching is the better default on modern Drupal — correct and fast, with no stale-content window.
  • Reach for time-based caching only when a View's data isn't tracked by Drupal's own cache tag system.
  • Caching is configured entirely through the View's own Advanced settings — no custom code needed for either plugin.

Coming up next

Caching solves the "don't repeat expensive work" problem. Next, we tackle making the expensive work itself cheaper in the first place — trimming down exactly which fields and filters a View's query actually needs to run.