[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  |     Focuses:  performance
--------------------------------------+--------------------------

Comment (by desrosj):

 I chatted with @flixos90 a bit today after going through and reviewing
 everything. here are a few thoughts!

 - Overall, I'm convinced that this will be beneficial the web as a whole
 despite the API still being only a draft, and despite only Chromium-based
 browsers supporting the feature. The market share for those browsers is
 over 80%, so the majority of users would benefit. The fact that other
 providers (Cloudflare,a few plugins, etc.) have implemented this also
 speaks to the overall confidence of the API in the wild.
 - I've been trying to think through how this could be abused either
 intentionally or unintentionally. If site owner has code that switches the
 `eagerness` to `immediate` or `eager`, it's possible that they
 inadvertently cause URLs from other plugins to be prefetched or
 prerendered. These links could be delete user links, subscribe links, etc.
 Another scenario could be where a plugin filters the list of exclusions
 and accidentally does not perform a merge and replaces exclude rules from
 other plugins.
 - The feature as proposed turns off the feature for all logged in users. I
 think that addresses these concerns even if the second scenario causes
 something to perform badly (every filter has the potential to be misused),
 but I'm wondering if it makes sense to prevent this from being turned on
 for logged-in users.
 - I'm also wondering if it makes sense to support `immediate` as an
 eagerness value at all. Perhaps for the initial implementation `immediate`
 can  only be supported for URL lists?

 Last question I have that @flixos90 was going to look into. Can we confirm
 that if there are multiple instances of `<script
 type="speculationrules">`, how is that handled? Are they merged? Is the
 last one on the page the one that's used? The first one?

 An extension of that question is how will this work if a site already has
 the API implemented either knowingly or unknowingly through a service
 provider like Cloudflare? Could we work with the bigger providers to
 ensure the rules provided by WordPress Core in 6.8+ are used instead of
 the ones that they've implemented separately?

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