Speculative loading considerations

[AntonyXSI]

Bug Description

I have used prefetching on hundreds of WordPress sites for 5+ years with great success to CWV metrics and improving the user experience in general. Good to see this being explored. It's great a feature, however I don't believe that speculative loading would be suitable as an on by default core feature. Due to it having the ability to decrease scalability by increasing server resource usage, particularly for sites on shared hosting servers. It really needs to be configured depending on the site/server resources available therefore would be best suited as a plugin.

Happy to share what default settings has worked for the sites I use it on:

1. Excluding logged in users. Prefetching really shines with page caching as the server is able to deliver the content almost instantly with near zero CPU usage without waiting for the page to be generated. Logged in visits are predominately dynamic non cacheable requests.

Using prefetching/prerendering on dynamic pages specifically on shared hosting where it can often take 1s+ for a page to be generated, would result in higher CPU usage and resources more easily bottlenecking. This is from pages being requested that may not be visited, as well as the ease/rate for links to be requested by hovering over them rather than manually when navigating through the site, and fundamentally the dynamic requests taking a lot longer. This affects the ability of the server to handle the same amount of traffic, and traffic spikes.

2. Excluding URLs with query strings. This would solve needing to manually exclude the nonce, add to cart strings etc. Another example would be plugins using href links for filters, wishlists etc. These plugins don't always abide by the practice of adding the nofollow tag to links. Query parameters URLs are often excluded by page caching plugins as well. Including these would increase CPU usage and potentially cause undesirable actions (adding items to the cart on). A blanket exclude seems to be the best option to avoid compatibility issues with different plugins and custom code.

3. Excluding links that contain "." or file extensions i.e to prevent a user from downloading large PDFs or images potentially bottlenecking bandwidth. An example would be images being wrapped in a link to the original uncropped image. Hovering over images in a gallery for example could result in lots of large unoptimized images being downloaded unnecessarily in the background. As images will begin to render almost instantly prerendering images, pdfs etc may not be as beneficial as prerendering pages. I'm also not sure what happens if .exe,.pdf or other large files are prefetched that would normally be downloaded once clicked? Does Chrome drop the request or continue the download from the same prefetch request? (Note: Excluding the uploads directory is implemented in Prevent speculatively loading links to the uploads, content, plugins, template, or stylesheet directories #1167.)

4. Prefetching has the potential to double response times when PHP sessions are used, as PHP requests will be queued. For instance if a page might take 3s to be generated, hovering over 1 link then clicking another would result in that second link responding in 6s rather then 3s since the server has to wait for the first request to be processed.

Interested to hear your thoughts and if there might be a workaround for the above issues or if a more conservative setting would be suitable for the speculation rules unless otherwise configured?

[westonruter]

Great suggestions!

1. Excluding logged in users.

Yeah, this makes sense. Perhaps there should be a filter to control whether speculation rules are added to a page. By default they could be omitted when the user is logged-in.

2. Excluding URLs with query strings.

What if pretty permalinks are disabled? (In this case all URLs have query strings.) Granted this is not common.

3. Excluding links that contain "." or file extensions

We should definitely exclude the uploads directory if not looking for file extensions. I'm not sure at the moment what happens with a link to a PDF.

4. when PHP sessions are used

So similar to the logged-in user, default to omitting speculation rules when there is a PHP session?

[westonruter]

3. Excluding links that contain "." or file extensions

We should definitely exclude the uploads directory if not looking for file extensions. I'm not sure at the moment what happens with a link to a PDF.

I can confirm that files in the uploads directory do currently attempt to get loaded. Images succeed but PDFs fail:

I wonder why Chrome doesn't prerender the PDF. Even though images can get prerendered, I don't think it makes sense to do so by default. If someone wants an instant loading of a large view of an image, they should enable the "click to expand" feature rather than link to the image file.

On that note, I just noticed that hovering over a click-to-expand image does not cause the full-size image to get prefetched.

Screen.recording.2024-04-18.15.57.10.webm

Note how even though I hover over the image, the full size image isn't fetched until I actually click the image. This results in the low resolution scaled-up image being displayed for longer than it has to be.

[westonruter]

I wonder why Chrome doesn't prerender the PDF.

I checked with @tunetheweb and he pointed me to this Chrome Limits section which links off to the Chromium source including these lines from the PreloadingEligibility enum:

  // Preloading was ineligible because it is not supported for WebContents.
  kPreloadingUnsupportedByWebContents = 15,

Apparently the PDF viewer isn't considered web content, even though it can be rendered inside of an iframe.

I just noticed that hovering over a click-to-expand image does not cause the full-size image to get prefetched.

Regarding the prefetching of click-to-expand images, I've opened WordPress/gutenberg#60883.

[westonruter]

1. Excluding logged in users.

Yeah, this makes sense. Perhaps there should be a filter to control whether speculation rules are added to a page. By default they could be omitted when the user is logged-in.

The ability to have speculation rules omitted by default for logged-in users came up today in the support forum.

One concern I have about doing this is that a user may activate Speculative Loading and then notice that the plugin doesn't seem to do anything. In this case, maybe it should be enabled for logged-out users and for admin users (who can activate plugins)? Presumably there would not be many admin users navigating around the site while being logged-in, so they wouldn't contribute significantly to the server load. What this means is that logged-in users who are not administrators would not get speculative loading by default, such as in the case of an e-commerce site or membership site.

There could be a filter to customize whether speculation rules are added to the page. For example, the plugin could do:

$should_print = apply_filters( 
    'plsr_print_speculation_rules', 
    ! is_user_logged_in() || current_user_can( 'activate_plugins' ) 
);

In this way, if a site wants to force speculation rules to always be printed, they could add this plugin code:

add_filter( 'plsr_print_speculation_rules', '__return_true' );

Or they could add their own arbitrary conditions for whether to print the speculation rules.

The important thing is to have the right defaults for the 80% of sites.

[westonruter]

In regards to disabling the printing of speculation rules when PHP sessions are used, this may warrant adding a Site Health test to warn when sessions active.

[felixarntz]

@westonruter and I discussed this the other day and came to the following conclusions:

• +1 to disabling speculative loading when the user is logged in. This is a bit safer and furthermore in line with excluding wp-admin.
• +1 to excluding URLs with query parameters. Of course this only works for sites with pretty permalinks enabled, which however is the default and probably enabled for ~99% of WordPress sites. For sites without pretty permalinks, we'll disable speculative loading by default, but provide a way to opt in to enabling it. That way site owners can decide if they're comfortable with the risk of not excluding URLs with custom query parameters.
• The file exclusions are already handled, both by the plugin now excluding URLs in e.g. uploads and plugins directories, but also the browser itself not speculatively loading any files.
• For PHP sessions, we can still consider this, but it doesn't seem a high priority now given how uncommon these are in WordPress world.

I have implemented #1784 with the relevant changes and related tweaks.