Speculative Loading: Change default eagerness from conservative to moderate when caching is detected

[westonruter]

This is a follow up to #62503 which introduced Speculative Loading (the Speculation Rules API) to core.

As described in the ​Speculative Loading in 6.8 dev note:

This default of prefetch with conservative eagerness is used as a reasonable starting point to enable speculative loading at the scale of WordPress. It is in line with the configuration that Cloudflare uses in its speculative loading feature, and it minimizes the chance of any speculative loads without a subsequent navigation to the URL.

The default prefetch and mode in core are set to auto:

For both configuration parameters, the value auto signifies that WordPress Core will decide on the configuration, which as of today effectively leads to a mode of prefetch and an eagerness of conservative. Depending on various criteria such as the state of the Speculation Rules API and ecosystem support, the behavior may change in a future WordPress release.

In the Speculation Rules API, the eagerness of conservative means that the browser will only start to prefetch the URL when the user starts to click/tap on a link (i.e. mousedown/pointerdown). This gives the navigation about a 50 millisecond head start versus waiting for the click event to finish. With the eagerness of moderate, however, the browser can start to prefetch the URL after the user has hovered over a link for 200 ms on desktop, or (newly) on mobile when a link is visible in the viewport along with some additional heuristics. See Chrome's ​Speculation rules eagerness improvements. I did a ​comparison on the impact that the different eagerness levels have on a WordPress site with a normal TTFB (for a WP site) of 1 second: While conservative shaves off 50 ms from that 1-second TTFB, an eagerness of moderate can reduce the perceived TTFB to zero milliseconds.

Nevertheless, a key reason for being conservative is to minimize the chance of unused speculative loads. This is to guard against the increased server load, while also being a sustainability concern. On many shared hosts, the additional traffic incurred by moderate may overtax their limited CPU resources. Nevertheless, this is also an issue when such a site sees an influx in visitors. In order to deal with such traffic spikes, the go-to solution is to use a ​page caching solution. In fact, WordPress 6.1 introduced a Site Health test via #56041 which specifically checks for the presence of a page cache.

As an additional safeguard, moderate eagerness can be contingent based on whether a persistent object cache is present, that is, whether wp_using_ext_object_cache() returns true. Note that a Site Health test for persistent object cache was introduced in #56040; it could be updated to note that enabling persistent object cache can increase the eagerness in speculative loading, which can also be noted in the Site Health test for page caching.

As noted in the dev note that the default eagerness “may change in a future WordPress release”, I'm proposing that the Site Health test for page cache could be leveraged as a signal to change the default eagerness from conservative to moderate.

Trac ticket: https://core.trac.wordpress.org/ticket/64066

Site Health tests for page cache and persistent object cache have been updated to notify that moderate becomes the default when both are present:

[westonruter]

As discussed during our Core Performance chat today: milestoning for 6.9 for visibility, but I realize this may likely need to get punted to Future Release to allow for additional considerations.

[westonruter]

Here's some plugin code that a host could, for example, drop into an mu-plugin to enable moderate eagerness by default unless a plugin (e.g. ​Speculative Loading) had set it to be something else:

<?php
add_filter(
        'wp_speculation_rules_configuration',
        /**
         * @param array<string, string>|null|mixed $config Config.
         * @return array<string, string>|null Filtered config.
         */
        static function ( $config ): ?array {
                // A plugin turned off Speculative Loading.
                if ( null === $config ) {
                        return null;
                }

                // In case a plugin returned a bad value to a filter.
                if ( ! is_array( $config ) ) {
                        $config = array();
                }

                // See <https://github.com/WordPress/wordpress-develop/blob/e1008a31dfcf6e9c395fa7f744139d11b2c1d9a7/src/wp-includes/speculative-loading.php#L21-L24>.
                $config = array_merge(
                        array(
                                'mode'      => 'auto',
                                'eagerness' => 'auto',
                        ),
                        $config
                );

                // Use a default eagerness of moderate if auto remains after all filters applied.
                if ( 'auto' === $config['eagerness'] ) {
                        $config['eagerness'] = 'moderate';
                }

                return $config;
        },
        PHP_INT_MAX // Allow other plugins (e.g. Speculative Loading) to easily override.
);

[westonruter]

Looks like this won't make it for 6.9, but let's discuss.

[westonruter]

Milestoning for visibility.

[westonruter]

See ​discussion in core dev chat.

This was also discussed in the bugscrub today.

The feedback I got from @jorbin and @desrosj was:

1. There needs to be clear communication to hosting providers and documentation in the field guide.
2. Data needs to be gathered on what the expected impact there will be on LCP as well as on the increase in page loads (potentially for wasted speculations).

A couple questions for @gilbertococchi (which I also left in #core-performance Slack):

1. I know you have data on LCP passing rates for sites with conservative prefetch versus moderate prefetch. What is the latest relative improvement you've seen? Granted, it would be better to look at a set of sites all on conservative and then only switch to moderate after a month to see what their respective passing rates are. (See ​Slack thread for replies.)
2. Also, is there any Chrome data for what is expected for the rate of wasted/unused speculations? The only way I'm aware of to measure this otherwise would be to look at a site that has very stable monthly traffic, and then flip from conservative to moderate after a month, and then to obtain the difference in the server hits in the access logs. (Although this also may not be reliable, if there is a random bot slamming a site one month but not the next.) (See ​Slack thread for replies.)

[westonruter]

Punting since we're too close to beta1 to land this. We need data to justify. So let's work on gathering that data for the next major release, starting in April.