Add Site Health test for full page caching (advanced cache) #220

Feature Description

I previously reported this in trac (#54423), but I'm copying it here for visibility:

A best practice for performance is to enable full page caching for a WordPress site. Doing so reduces the time to first byte (TTFB) and thus directly impacts Core Web Vitals. This is especially important on shared hosts which have limited compute power, while also protecting a site from going down due to traffic spikes.

As with XML Sitemaps, it may make sense for WordPress core to include a basic full page caching solution out of the box which can be extended by the many plugins that provide page caching today. In the meantime, there should at least be a Site Health test with a low-severity recommended status to point users to where to go to enable page caching. Since hosts often have built-in caching solutions in place, the Site Health test should be easily filterable so they can provide a link to their specific dashboard or documentation to enable caching which may not be a plugin at all but rather a reverse proxy like Varnish.

In the context of the AMP plugin for WordPress, we've already developed such a test which could be adapted for core. See ampproject/amp-wp#6456. It's an async test which issues three loopback requests to the homepage, and the test will pass if responses include either of the following headers:

1. Cache-Control with non-zero max-age.
2. Expires with a future time.
3. Age with a positive number (as is set via a proxy like Varnish).

Since the above was written and, after releasing the page caching site health test in the AMP plugin v2.2, it came to light that the detection was not robust enough. A major improvement followed (ampproject/amp-wp#6849) which accounts for many more scenarios (ampproject/amp-wp#6849 (comment)). These were uncovered with help from @piotrbak in a WP Rocket issue (wp-media/wp-rocket#4638 (comment)).

The page caching code in question: https://github.com/ampproject/amp-wp/blob/f7c7230a27fb23932606f9847bfcf04c83b8ff06/src/Admin/SiteHealth.php#L333-L661

Scenarios

Via ampproject/amp-wp#6849 (comment):

Failure to Do Loopback Request

With this plugin active:

add_action('template_redirect', function () {
	status_header( 500 );
	exit;
});

No Page Caching with Slow Response Time

With this plugin active:

add_action( 'wp_footer', function () {
	sleep(1);
} );

No Page Caching with Good Response Time

No special plugins active.

Page Caching Header(s) with Bad Response Time

Test plugin:

add_filter(
	'wp_headers',
	function ( $headers ) {
		$headers['etag'] = '"foo"';
		$headers['last-modified'] = gmdate('r');
		return $headers;
	}
);

add_action( 'wp_footer', function () {
	sleep(1);
} );

Note that since page caching response headers are present, the lack of a page caching plugin is not mentioned (since it's likely an external page cache is being used):

Page Caching Header with Good Response Time

Plugin:

add_filter(
	'wp_headers',
	function ( $headers ) {
		$headers['etag'] = '"foo"';
		$headers['last-modified'] = gmdate('r');
		return $headers;
	}
);

Note that since page caching response headers are present, the lack of a page caching plugin is not mentioned (since it's likely an external page cache is being used):

Page Caching Plugin with Good Response Time

With WP Super Cache active and with the following plugin active:

add_action( 'wp_footer', function () {
	sleep(1);
} );

Note that since the median time is used, the 1-second response time is disregarded: