Drupal's caching architecture is more sophisticated than most CMS caching layers. Drupal cache uses a combination of cache tags, cache contexts, cache max-age, and pluggable cache backends to compose page output from cacheable parts. Understanding how the layers actually work is what separates configured-but-broken caching from caching that produces sustained performance under load. This post is the institutional Drupal cache mechanics deep-dive.
We covered the layered performance pattern in 10 Tips to Improve Drupal Website Performance and the broader hosting context in Why Host Drupal on AWS. This post focuses on the cache mechanics specifically.
The Core Cache Concepts
Drupal's caching system is built around three concepts that compose to produce cached output:
Cache tags. Identify what cached items depend on. When the underlying content changes, the cache tag is invalidated, and any cached output that depends on that tag is automatically refreshed. Examples: node:42 for a specific node, user:1 for a specific user, node_list for any change to any node, config:system.site for site-wide configuration.
Cache contexts. Identify what makes the cached output vary. Examples: user (per-user variation), user.permissions (per-permission-set variation), route (per-route variation), languages:language_interface (per-language variation). Cache contexts let Drupal cache different versions of the same render array for different users or contexts.
Cache max-age. Identifies how long the cache can be considered valid. Most institutional cache max-age values are either Permanent (until explicitly invalidated) or zero (uncacheable). Time-bounded max-age is rare in practice.
These three combine: a render array's cache metadata says "this output is cached, it depends on these tags, varies by these contexts, and is valid for this max-age." Drupal computes a cache key from the contexts, stores the rendered output keyed by tags, and serves from cache until the tags invalidate.
The Cache Layers in a Drupal Request
A Drupal request flows through multiple cache tiers, each catching a portion of work:
External: CDN cache. CloudFront, Cloudflare, Fastly, or institutional CDN caches the full HTML response for anonymous users by URL. Cache hit returns without ever reaching the origin. Cache TTL is configured at the CDN; Drupal can also send Cache-Control headers that the CDN respects.
External: Reverse proxy cache. Varnish (where deployed) sits between the CDN and Drupal. Varnish caches by URL plus configured request headers. Cache hit returns without invoking PHP.
Drupal: Page cache. Drupal's internal page cache for anonymous users. Caches the full HTML response. Functionally similar to Varnish but slower (it goes through PHP) and less common in institutional deployments where Varnish is in front.
Drupal: Dynamic page cache. Caches partial page output for authenticated users. Per-user variations are handled by cache contexts. The dynamic page cache substantially reduces work for authenticated requests.
Drupal: Render cache. Caches individual render arrays (blocks, fields, formatters). The most granular tier. A block that renders the same way for many users only renders once and is served from render cache for subsequent requests.
Drupal: Entity cache. Caches loaded entity objects. Substantially reduces database query count.
Drupal: Cache backend. All Drupal cache layers store data through a cache backend. Default is the database. Better backends: Redis, Memcached. Institutional Drupal on AWS commonly uses ElastiCache for Redis.
How Cache Invalidation Works
Cache invalidation is the institutional Drupal performance topic that gets the least attention and causes the most production issues.
When content changes, the cache tags associated with that content are invalidated. Anything cached with those tags is removed (or marked stale) on next access. This is the strength of Drupal's caching: invalidation is surgical, not blanket. Editing a single node invalidates only the cache entries that depend on that node.
The institutional discipline:
Cache tag discipline in custom code. Custom Drupal code that emits render arrays must declare cache tags accurately. Code that bypasses cache tags (returning markup without the right metadata) creates uncacheable surfaces or stale-content surfaces.
Cache tag invalidation through the right API. Code that invalidates caches uses the cache tag invalidation service, not direct cache deletion. Direct deletion bypasses the cross-tier propagation.
External cache invalidation propagation. When Drupal invalidates internal cache tags, the external CDN or Varnish does not automatically know. The Purge module bridges the gap: it captures Drupal cache tag invalidations and propagates them to the external cache through purge operations.
Tag granularity. Institutional Drupal benefits from intentional tag design. Tags that are too broad (node_list everywhere) cause excessive invalidation. Tags that are too narrow (per-render-array unique tags) reduce sharing and increase cache size.
What "Configured" vs "Working" Cache Looks Like
Configured but broken Drupal caching is a common institutional problem. Symptoms:
High cache hit rates but slow response times. The cache backend is responding but the data is stale or the wrong granularity. Audit cache contexts for over-variation (caching the same content thousands of times for irrelevant context distinctions).
Cache invalidation that doesn't propagate. Content edits don't show up on the live site because the CDN or Varnish layer is not being purged. Audit the Purge module configuration and the cache tag propagation.
Cache tag explosion. The cache backend size is growing faster than expected. Audit which code is emitting cache tags and verify the tags are intentional.
Per-user cache for content that should be shared. Authenticated user cache hit rates are low because the cache contexts are over-specified. Audit cache contexts on commonly-rendered components (header, footer, menus).
Working Drupal caching looks like: high cache hit rate at the CDN, fast cache hit on Varnish or page cache, sub-100ms render time for cache misses, surgical invalidation on content changes, and stable cache size that grows with content volume rather than user activity.
What Mature Institutional Drupal Cache Operations Looks Like
Institutional Drupal sites with mature cache operations have:
Cache backend on Redis or Memcached. Database cache backend is the default but is the slowest option. Institutional deployments use Redis (preferred) or Memcached.
External cache (Varnish or CDN) with proper invalidation. Purge module configured for the external cache. Cache tag propagation tested.
Cache tags audited in custom code. Custom modules and themes declare cache tags accurately. Code review includes cache metadata validation.
Cache hit rate monitoring. CDN cache hit rate, Varnish hit rate, and Drupal internal cache hit rates monitored. Drops in hit rate flagged as performance regressions.
Documented cache invalidation flow. When content changes, the documented invalidation flow describes what cache layers refresh and when. The flow is exercised by content team workflow.
For managed Drupal hosting engagements supporting institutional Drupal workloads, this cache discipline is part of the engagement scope.
Frequently Asked Questions
Should institutional Drupal use Drupal's internal page cache or Varnish?
For institutional deployments at scale, Varnish (or a CDN with similar capability) in front of Drupal. Drupal's internal page cache is functional but invokes PHP for cache hits, which is slower than Varnish's sub-millisecond response. For smaller institutional sites without Varnish infrastructure, the internal page cache is acceptable.
How does BigPipe relate to Drupal's caching?
BigPipe is a Drupal feature that streams the cacheable parts of a page first and the user-specific parts later, in the same response. It reduces perceived load time for authenticated users by getting the cached parts to the browser quickly. BigPipe is enabled by default in Drupal core.
What is a typical CDN cache hit rate for institutional Drupal?
For sites with high anonymous traffic and reasonable cache TTL: 80 to 95 percent. For sites with high authenticated traffic, lower (the CDN does not cache authenticated content). Institutional sites with predominantly anonymous public traffic should see CDN hit rates above 90 percent with proper configuration.
How does this differ from WordPress caching?
WordPress caching is simpler but less granular. WordPress page caching handles the most common cases well but lacks the surgical invalidation that Drupal cache tags provide. For high-content-velocity institutional sites, Drupal's cache architecture is operationally easier to reason about. For lower-velocity content sites, WordPress caching is adequate.