Feature description

AMP will soon support valid AMP pages opting out of being served from an AMP Cache. See ampproject/amphtml#29296. This will be an important ability to fix various issues caused by caching, including analytics and serving stale pages (ampproject/amphtml#24326), the latter of which is particularly important for e-commerce.

Opting out of AMP Cache by default seems also important for non-singular templates, or any post/page that has frequent updates. For example, the homepage of a site (and any other archive pages) should probably not be served by the AMP Cache by default until there is a reliable way to ensure the AMP Cache is flushed (see #598). We could also have a list of post types from popular e-commerce plugins that we disable by default for AMP Cache.

👉 This is blocked from being closed until the feature lands in upstream. However, work can begin on implementing support as well as figuring out what the right defaults are. We also need to determine what UI (if any) is added for this. For example, there may need to be a new advanced section for AMP Cache handling which contains whether AMP Cache is enabled/disabled overall. Nevertheless, there could be fine-grained controls over whether AMP Cache is enabled, down to the post type and template level. If so, then this could be combined with the Supported Templates section somehow, where the current on/off toggles are replaced with a multi-value dropdown:

• Disabled
• Enabled (without caching)
• Enabled (with caching)

This could also extend to the "AMP Enabled" toggle on individual posts and pages.

Relation to Bento AMP

This is also closely related to how we might need to adjust terminology for Bento AMP. When themes and plugins can use AMP components on non-AMP pages, it's not accurate to say that “AMP” can be disabled. It's more whether or not “AMP validation” is disabled. In this way, the AMP plugin could continue to inject AMP components into the responses for non-AMP pages, such as in oEmbed handlers or in converting img into amp-img to get the speed benefits that AMP provides (although amp-img specifically is on a deprecation path now that lazy-loaded images are part of the platform, per ampproject/amphtml#29786).

There are also implications here for AMP Optimizer. if we serve AMP components on non-AMP pages, we should make sure they get server-side rendered (SSR) as much as possible since the AMP Boilerplate will not be present. Currently AMP Optimizer takes complete AMP documents in DOM as input. The oEmbed handlers, however, only manipulate HTML strings. So either the oEmbed handlers need to create transformed AMP manually, or we need to constrict DOM fragments and pass them into the Optimizer for processing.

Do not alter or remove anything below. The following sections will be managed by moderators only.

Acceptance criteria

• The desired pages on which AMP Cache are disabled should be served with amp="no-caching" in the html attribute.
• 80% use cases of users needing control over disabling AMP Cache should be accounted for (TBD).

Implementation brief

• Similar to AMP Dev Mode with its amp_dev_mode_enabled filter, introduce an amp_cache_enabled filter. The default value should be true for singular queries, and false for archives (and perhaps other select post types).
• As with AMP Dev Mode's AMP_Dev_Mode_Sanitizer, introduce an AMP_Off_Cache_Sanitizer which is added to the list of amp_content_sanitizers when amp_cache_enabled is filtered to be false. This sanitizer will set the amp attribute on the html element to be off-cache (tentatively).
• TBD on UI. Note that any UI would conflict with programmatic control via the amp_dev_mode_enabled filter. So if a site has_filter('amp_dev_mode_enabled') then any cache options must be disabled.

QA testing instructions

Demo

Changelog entry