Cache Drupal pages without leaking personalized content

Caching improves a website when stored output can be reused for the right request. Problems arise when a component varies by a user, permission, language, or query parameter but its cache metadata does not describe that variation. The same discipline is needed when content changes after a page has already been cached.

Describe what can change the output

Cache contexts identify variations such as permissions or query arguments. Cache tags connect output to the data that should invalidate it. A maximum age limits how long a result can be reused. These mechanisms are complementary. Setting a short lifetime does not correct a missing access-related variation.

Keep entity access and render metadata together

Use Drupal entity access checks and render arrays rather than querying and printing raw records. A listing needs to respond when items are added, removed, or unpublished, so individual item tags alone may not describe the whole result. Components that build filtered lists should account for both the list and the relevant request parameters.

Test changes after warming the cache

Load a page as an anonymous visitor, then edit or unpublish the content and request it again. Repeat with users whose permissions differ. Check filtered listings and empty results as well as detail pages. These tests reveal problems that are invisible when every request starts with a freshly rebuilt cache.

A practical next step

Choose one custom listing and document its data dependencies, access rules, and request variations. Turn each into a cache-warming test that checks the rendered output before and after the relevant change.