[wp-trac] [WordPress Trac] #62503: Add speculative loading support

[WordPress Trac]

#62503: Add speculative loading support
-------------------------------------------------+-------------------------
 Reporter:  flixos90                             |       Owner:  flixos90
     Type:  feature request                      |      Status:  assigned
 Priority:  high                                 |   Milestone:  6.8
Component:  General                              |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-unit-tests needs-dev-  |     Focuses:
  note                                           |  performance
-------------------------------------------------+-------------------------
Changes (by flixos90):

 * keywords:  has-patch has-unit-tests => has-patch has-unit-tests needs-
     dev-note


Comment:

 Thanks for the feedback and notes @desrosj.

 A few additional notes and replies:
 * Iterating on what you mentioned about "action URLs", the requirements
 for not being logged-in, requiring use of pretty permalinks, and then
 excluding any URLs with query parameters should mitigate those concerns.
 * Sites without pretty permalinks or sites that are primarily used by
 logged-in users (like membership sites) can still override this behavior,
 for cases where the developer is confident their site would not suffer
 from such side effects (either because there are no "action URLs" present
 across their site or because they already added extra exclusions to
 prevent the issue). This obviously requires caution and should be clearly
 called out in the dev note. Yet despite the risk, preventing these sites
 from using WordPress Core's built-in Speculation Rules implementation
 entirely would be undesirable because developers should certainly be able
 to make educated decisions on their site's eligibility for that.
 * As you're saying, the `immediate` eagerness value would amplify that
 risk and it's actually fair to raise that it should not be allowed for
 `document` level speculation rules. The Speculative Loading plugin never
 supported that value, and I only added support for it to the Core PR
 because it is more comprehensive than the plugin as it also supports
 specific URL `list` speculation rules. For the latter, using `immediate`
 can certainly be valuable. But for `document` rules, while it is
 technically allowed, I agree with you that the risk of allowing it is
 probably greater than the benefit. As such, I just amended the PR so that
 `immediate` can only be used for specific URL `list` speculation rules.
 This also means the overall configuration for WordPress's main rule cannot
 use `immediate` eagerness either.

 Regarding multiple instances of speculation rules being present from
 different sources:
 * The browser respects all of them, effectively merging them - whether
 they come from different `<script type="speculationrules">` tags or HTTP
 headers. So overall there shouldn't be a concern one instance conflicting
 with another instance, unless specific speculation rules from different
 sources would conflict with each other. More on that below.
 * If a site was using a plugin which injects a `<script
 type="speculationrules">` tag that configures the browser to prerender, it
 would effectively override WordPress Core's more conservative
 implementation of prefetching. That wouldn't be unexpected though if you
 had that plugin installed, and it would be similar to a plugin modifying
 WordPress Core's behavior via the provided filters.
 * For WordPress sites using Cloudflare, at a high level there shouldn't be
 conflicts because the implementations are both using conservative
 prefetch. If Cloudflare at some point decided to make their implementation
 more eager, then this would override / build on top of WordPress's
 behavior, but the end result would be the same as if WordPress didn't have
 speculation rules at all. Conversely, if WordPress in the future used a
 more eager implementation, it would override/build on top of Cloudflare's
 behavior.
 * The only potential caveat with Cloudflare is that it wouldn't have the
 same exclusion measures in place since it's of course not built ''for''
 the WordPress stack. In other words, WordPress sites using Cloudflare
 would not be able to benefit from these exclusions and it may be advisable
 for these site owners to disable Cloudflare's speculation rules in favor
 of WordPress Core's ones that are more optimized for its own stack. But
 even with both present, the behavior of the site remain the same as it
 already was before WordPress included speculation rules, so there's
 effectively no problem introduced by this change.
 * Last but not least, it's worth noting that even in case of multiple
 instances of speculation rules the browser would still keep its overall
 limits on how many URLs can be prefetched or prerendered, so if that limit
 was 10, and two different speculation rules implementations would each
 lead to 8 URLs being prefetched/prerendered, it would only happen for the
 first 10. But that's how it works even for a single implementation.

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