[wp-trac] [WordPress Trac] #64066: Speculative Loading: Change default eagerness from conservative to moderate when caching is detected (was: Speculative Loading: Change default eagerness from conservative to moderate when page cache is detected)

[WordPress Trac]

#64066: Speculative Loading: Change default eagerness from conservative to moderate
when caching is detected
--------------------------------+------------------------------------------
 Reporter:  westonruter         |       Owner:  (none)
     Type:  enhancement         |      Status:  new
 Priority:  normal              |   Milestone:  Awaiting Review
Component:  General             |     Version:  6.8
 Severity:  normal              |  Resolution:
 Keywords:  2nd-opinion has-    |     Focuses:  performance, sustainability
  patch                         |
--------------------------------+------------------------------------------
Description changed by westonruter:

Old description:

> This is a follow up to #62503 which introduced Speculative Loading (the
> Speculation Rules API) to core.
>
> As described in the [https://make.wordpress.org/core/2025/03/06
> /speculative-loading-in-6-8/ 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
> [https://docs.google.com/document/d/1YPbtUPfZIDElzBZNx8IQMzRFvy8oauLG_i1XIr6jgTs/edit?usp=sharing
> Speculation rules eagerness improvements]. I did a
> [https://weston.ruter.net/2025/08/27/the-site-speed-frontier-with-
> performance-lab-and-beyond/#speculative-loading 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
> [https://developer.wordpress.org/advanced-
> administration/performance/optimization/#caching 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 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`.

New description:

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

 As described in the [https://make.wordpress.org/core/2025/03/06
 /speculative-loading-in-6-8/ 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
 [https://docs.google.com/document/d/1YPbtUPfZIDElzBZNx8IQMzRFvy8oauLG_i1XIr6jgTs/edit?usp=sharing
 Speculation rules eagerness improvements]. I did a
 [https://weston.ruter.net/2025/08/27/the-site-speed-frontier-with-
 performance-lab-and-beyond/#speculative-loading 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 [https://developer.wordpress.org
 /advanced-administration/performance/optimization/#caching 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`.

--

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64066#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform