Consider allowing page_cache in sanity check

[erikerskine]

The page_cache module does no harm and is useful in certain situations.

Consider allowing it, specifically for setups like the following:

• No CDN
• Upsun cache
• Drupal
• External cache max-age = 1 hour
• A page with content that is expensive to render but seldom changes

Without page_cache

1. Very first request goes all the way though to Drupal and is expensive.
2. Subsequent requests within the next hour hit the Upsun cache and do not bother Drupal. All good.
3. After an hour the Upsun cache becomes stale and we go back to step 1.

With page_cache

1. Very first request goes all the way though to Drupal and is expensive.
2. Subsequent requests within the next hour hit the Upsun cache and do not bother Drupal. All good.
3. After an hour the Upsun cache becomes stale. But the page_cache is not stale. So we serve the content from the page_cache and avoid rendering the expensive content again.
4. Steps 2 & 3 then repeat until the page is edited, then we go back to step 1.

All of this is because we can use tag-based invalidation for page_cache but can't use it for the Upsun cache. Drupal controls the page_cache, things sit there indefinitely, until they are purposely invalidated when something changes.

Suggestion

• When we do have a CDN we can invalidate (Fastly, CF) = leave things as they are
• When we don't have a CDN we can invalidate = consider adding page_cache as an extra layer