All articles
Performance

Drupal Caching Explained with a Shared Service Card

By
Druproid Support
Published
Use a simple content example to understand cache tags, cache contexts, and cache lifetime without losing editorial updates.
Technology platform illustration showing connected digital tools

Imagine a service card that appears on the homepage and on a services page. An editor changes its description and expects both pages to update. A good caching implementation should reuse previous rendering work while still knowing when that work is out of date.

Ask three questions

Drupal cache metadata answers three different questions. Tags describe dependencies that can invalidate cached output. Contexts describe variations, such as language or permissions. Maximum age describes how long an item may remain cacheable. The Drupal Cache API reference explains those concepts and their interfaces.

Apply them to the card

The card depends on a content entity. When that entity changes, cached pages containing it need to stop using the old rendering. If the card’s visibility depends on a permission, the rendered result also needs to account for that variation.

We recommend testing this as a small editorial story: open both pages anonymously, edit the shared card, and open both again. Then unpublish the card and repeat the check. This is a stronger test than confirming that a cache rebuild makes the change appear.

Avoid hiding the underlying problem

Clearing all caches can be useful while investigating, but a site should not need a manual cache rebuild every time a description changes. Likewise, disabling caching broadly can conceal a missing dependency while increasing the amount of work required for every request.

When developers render referenced content, ask whether they are using Drupal’s entity rendering and carrying its cache metadata into the parent output. A string assembled from database values may need additional work to preserve those dependencies.

Remember the layers outside Drupal

Your browser, reverse proxy, or CDN may cache a response too. If a change is visible to one person but not another, identify which layer supplied the older version. Record response headers and the exact URL rather than repeatedly changing settings at random.

For a focused investigation, bring a reproducible example to Druproid Support: the field changed, the pages affected, and the account used to view them.