Speculative Loading

The following example ensures that URLs like https://example.com/cart/ or https://example.com/cart/foo are excluded from prefetching and prerendering:

<?php
add_filter(
'plsr_speculation_rules_href_exclude_paths',
function ( array $exclude_paths ): array {
$exclude_paths[] = '/cart/*';
return $exclude_paths;
}
);

Keep in mind that sometimes it may be useful to exclude a URL from prerendering while still allowing it to be prefetched. For example, a page with client-side JavaScript to update user state should probably not be prerendered, but it would be reasonable to prefetch.

For this purpose, the plsr_speculation_rules_href_exclude_paths filter receives the current mode (either "prefetch" or "prerender") to provide conditional exclusions.

The following example ensures that URLs like https://example.com/products/... cannot be prerendered, while still allowing them to be prefetched:

<?php
add_filter(
'plsr_speculation_rules_href_exclude_paths',
function ( array $exclude_paths, string $mode ): array {
if ( 'prerender' === $mode ) {
$exclude_paths[] = '/products/*';
}
return $exclude_paths;
},
10,
2
);

As mentioned above, adding the no-prerender CSS class to a link will prevent it from being prerendered (but not prefetched). Additionally, links with rel=nofollow will neither be prefetched nor prerendered because some plugins add this to non-idempotent links (e.g. add to cart); such links ideally should rather be buttons which trigger a POST request or at least they should use wp_nonce_url().
Are there any special considerations for speculative loading behavior?
For safety reasons, the entire speculative loading feature is disabled by default for logged-in users and for sites that do not use pretty permalinks. The latter is the case because plugins often use URLs with custom query parameters to let users perform actions, and such URLs should not be speculatively loaded. For sites without pretty permalinks, it is impossible or at least extremely complex to differentiate between which query parameters are Core defaults and which query parameters are custom.

If you are running this plugin on a site without pretty permalinks and are confident that there are no custom query parameters in use that can cause state changes, you can opt in to enabling speculative loading via the plsr_enabled_without_pretty_permalinks filter:

<?php
add_filter( 'plsr_enabled_without_pretty_permalinks', '__return_true' );

For client-side JavaScript, is recommended to delay these until the prerender is activated (for example by clicking on the link). Some solutions (like Google Analytics) already do this automatically, see Impact on Analytics. Additionally, cross-origin iframes are not loaded until activation which can further avoid issues here.

Speculating with the default moderate eagerness decreases the risk that the prerendered page will not be visited by the user and therefore will avoid any side effects of loading such a link in advance. In contrast, eager speculation increases the risk that prerendered pages may not be loaded. Alternatively, the plugin offers to only speculate on mouse/pointer down (conservative) which reduces the risk even further and is an option for sites which are concerned about this, at the cost of having less of a lead time and so less of a performance gain.

A prerendered page is linked to the page that prerenders it, so personalisation may already be known by this point and changes (e.g. browsing other products, or logging in/out) often require a new page load, and hence a new prerender, which will then take these into account. But it definitely is something to be aware of and test! Prerendered pages can be canceled by removing the speculation rules <script> element from the page using standard JavaScript DOM APIs should this be needed when state changes without a new page load.
Where can I submit my plugin feedback?
Feedback is encouraged and much appreciated, especially since this plugin may contain future WordPress core features. If you have suggestions or requests for new features, you can submit them as an issue in the WordPress Performance Team's GitHub repository. If you need help with troubleshooting or have a question about the plugin, please create a new topic on our support forum.
Where can I report security bugs?
The Performance team and WordPress community take security bugs seriously. We appreciate your efforts to responsibly disclose your findings, and will make every effort to acknowledge your contributions.

To report a security issue, please visit the WordPress HackerOne program.
How can I contribute to the plugin?
Contributions are always welcome! Learn more about how to get involved in the Core Performance Team Handbook.