[wp-trac] [WordPress Trac] #64066: 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 page cache is detected
-----------------------------------------+-----------------------------
 Reporter:  westonruter                  |      Owner:  (none)
     Type:  enhancement                  |     Status:  new
 Priority:  normal                       |  Milestone:  Awaiting Review
Component:  General                      |    Version:  6.8
 Severity:  normal                       |   Keywords:  2nd-opinion
  Focuses:  performance, sustainability  |
-----------------------------------------+-----------------------------
 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`.

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