Port Audit Full Page Cache from performance plugin to core

[furi3r]

As part of the performance module life cycle, we want to port this site health check to the core.
​https://github.com/WordPress/performance/tree/trunk/modules/site-health/audit-full-page-cache

[hellofromTonya]

Duplicate of #56040.

[furi3r]

@hellofromTonya I did a mistake when creating the ticket with the same title as the previous one, but updated after. This is indeed another Trac ticket (see the difference in the title), also the link to a different module.

Performance GH issue link: ​https://github.com/WordPress/performance/issues/391

[hellofromTonya]

Aha, yeah, it looked like a duplicate. Thanks @furi3r for updating it. Cheers :)

Introducing Full Page Cache check into Site Health

Trac ticket: #56041

@Clorith @swissspidy @spacedmonkey feedback applied.

1. Consistent and accessible badge color policy.
2. Fixed translation comments.
3. Do we need to use wp_safe_remote_get?

@felixarntz thanks for the feedback. I've replaces all "page caching" appearances with "page cache".

@felixarntz I've updated the PR with trunk and solved the conflicts. All good!

[flixos90]

In 54043:

Site Health: Introduce page cache check.

This changeset adds a new page_cache check which determines whether the site uses a full page cache, and in addition assesses the server response time. If no page cache is present and the server response time is slow, the check will suggest use of a page cache.

A few filters are included for customization of the check:

• site_status_good_response_time_threshold filters the number of milliseconds below which the server response time is considered good. The default value is based on the server-response-time Lighthouse audit and can be altered using this filter.
• site_status_page_cache_supported_cache_headers filters the map of supported cache headers and their callback to determine whether it was a cache hit. The default list includes commonly used cache headers, and it is filterable to support e.g. additional cache headers used by specific vendors.

Note that due to the nature of this check it is only run in production environments.

Props furi3r, westonruter, spacedmonkey, swissspidy, Clorith.
Fixes #56041.

Committed in https://core.trac.wordpress.org/changeset/54043.

[flixos90]

Reopening this for the necessary dev note. It makes sense to cover this together with #56040 in a single dev note.

[SergeyBiryukov]

In 54044:

Site Health: Minor i18n cleanup in page cache and persistent object cache tests.

Includes:

• Moving leading and trailing spaces out of a translatable string.
• Using the established format for translator comments.
• Using a consistent typography for the apostrophe.

Follow-up to [53955], [54043].

See #56041.

[flixos90]

Looks like there is a test in here that is sometimes failing, as seen in ​https://github.com/WordPress/wordpress-develop/runs/8125555737. We have been discussing this in ​https://wordpress.slack.com/archives/C02RQBWTW/p1661992665658499, potentially the problem is a timing issue with the data provider and when the test is executed (since the value there is set to 10 minutes later, but the test suite often takes longer than that). We can't reproduce that consistently, but will attempt setting it to HOUR_IN_SECONDS instead.

[SergeyBiryukov]

In 54045:

Tests: Increase the time difference for the expires header in Site Health page cache tests.

This aims to avoid a race condition in the Code Coverage Report, which takes longer than 10 minutes to run, and by the time the page cache test runs, the expires header that is supposed to be in the future is already in the past.

Follow-up to [54043].

Props Clorith, davidbaumwald, flixos90, desrosj, SergeyBiryukov.
See #56041.

[costdev]

Fixes the @return type for the 'site_status_page_cache_supported_cache_headers' filter and uses str_contains() (polyfilled in WP 5.9)

[costdev]

On my travels, I noticed that the documented @param for the 'site_status_page_cache_supported_cache_headers' filter was int, but should be array.

Also suggest using str_contains() (polyfilled in WP 5.9) instead of false !== strpos() for readability.

[costdev]

Also just a brief heads up: ​A run of Tests_Site_Health::test_object_cache_default_thresholds() failed on an unrelated PR. This might've been a blip, but just drawing attention to this in case it needs more investigation.

[SergeyBiryukov]

In 54047:

Site Health: Some documentation and test improvements for WP_Site_Health:

• Add a @coversDefaultClass annotation to address @covers ::get_test_page_cache" is invalid notices.
• Rename data providers to start with the data_ prefix and match the test method names, for consistency.
• Move data providers next to the test methods they are used in.
• Move ::get_test_page_cache() closer to ::get_test_persistent_object_cache(), for a bit more predictable placement.
• Fix a typo in ::get_test_persistent_object_cache() description.

Follow-up to [53955], [54043], [54044], [54045].

See #56041.

[desrosj]

Is the only thing remaining here a dev note? It's not clear if 56041.diff​ was in [54047]. If only the dev note remains, let's close this out ahead of beta 1 today and use the keyword to keep track of this.

[JeffPaul]

As discussed ahead of today's scheduled 6.1 Beta 1 release party (see the Slack link above), it was deemed that this ticket was good to be closed and if something other than a dev note is required it could be handled in a new ticket or reopen this ticket as necessary.

[spacedmonkey]

There is a draft of a dev note available ​here.

[milana_cap]

Dev note: ​https://make.wordpress.org/core/2022/10/06/new-cache-site-health-checks-in-wordpress-6-1/

[westonruter]

#54423 was marked as a duplicate.