Skip to content

Instantly share code, notes, and snippets.

@schnippy
Last active March 4, 2026 21:22
Show Gist options
  • Select an option

  • Save schnippy/4709b9a5ef9d9ea22eaaa005e824bdf5 to your computer and use it in GitHub Desktop.

Select an option

Save schnippy/4709b9a5ef9d9ea22eaaa005e824bdf5 to your computer and use it in GitHub Desktop.

Drupal Internal Page Cache behind a CDN

Is the Internal Page Cache Module Necessary?

For a site behind a CDN, the short answer is no — the Internal Page Cache module is not necessary, and disabling it is likely the right move.


What Internal Page Cache Actually Does

The page_cache module stores full HTML page responses in Drupal's cache backend (Redis, in a typical Pantheon setup) and serves them to anonymous users by intercepting the request early in the bootstrap process, before Drupal fully initializes. Its value proposition is avoiding a full Drupal bootstrap for anonymous page requests.


Why It's Redundant Behind a CDN

Fastly is already performing this exact function — storing and serving full anonymous page responses — but doing it more efficiently at the edge, geographically closer to users, and at much greater scale than Redis can. The requests that actually reach your origin are already CDN cache misses (new content, uncacheable URLs, cache-busted items, etc.). For those requests, the Internal Page Cache is unlikely to help much either, since those pages often aren't in Redis yet.


The Redis Overhead Problem

With Internal Page Cache enabled, every anonymous request that reaches origin triggers:

  • A Redis read to check whether the full page HTML is cached
  • A Redis write to store the full rendered HTML on a cache miss

Full rendered HTML is large. These blobs consume meaningful Redis memory and generate significant I/O, crowding out more valuable cache entries like render cache fragments, entity caches, and Dynamic Page Cache entries.


Recommendation

Disable page_cache (Internal Page Cache), but keep dynamic_page_cache (Internal Dynamic Page Cache) enabled.

The Dynamic Page Cache module is genuinely valuable even behind a CDN because it:

  • Handles personalized and authenticated content using cache contexts and placeholder lazy-building — things a CDN can't do
  • Caches at the render array level rather than full HTML, so its entries tend to be more reusable and cache-efficient

After disabling Internal Page Cache, the Redis memory freed up by removing full HTML blobs will be better utilized by the render cache and entity cache, which benefit all requests — including authenticated ones that the CDN doesn't cache at all.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment