Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add filter for whether speculation rules are printed and default to not when user is logged-in non-admin or PHP session is active #1178

Draft
wants to merge 1 commit into
base: trunk
Choose a base branch
from

Conversation

westonruter
Copy link
Member

@westonruter westonruter commented Apr 24, 2024

See these points raised by @AntonyXSI in #1157:

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.

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.

Note that a site can already disable speculative loading using the following plugin code with the existing codebase:

add_action( 'init', static function () {
	if ( is_user_logged_in() ) {
		remove_action( 'wp_footer', 'plsr_print_speculation_rules' );
	}
} );

So adding a filter is not strictly required.

To Do

  • Add tests.
  • Update README with docs on new filter and conditions for when speculation rules are not printed by default.
  • Add note in Reading settings about when it is disabled by default. Should the off-by-default for logged-in user behavior be an option?
  • Add Site Health test for PHP Sessions being used on the frontend?
  • Consider adding a toggle to the settings section for whether speculative loading is enabled for logged-in users? Would this be an alternative to the filter?
  • Could we hook into the page caching site health test to conditionally disable speculative loading for logged-in users when page caching is absent?

@westonruter westonruter added [Type] Enhancement A suggestion for improvement of an existing feature [Plugin] Speculative Loading Issues for the Speculative Loading plugin (formerly Speculation Rules) labels Apr 24, 2024
@westonruter westonruter added this to the speculation-rules n.e.x.t milestone Apr 24, 2024
@joemcgill joemcgill self-requested a review April 30, 2024 15:30
@westonruter westonruter removed this from the speculation-rules n.e.x.t milestone May 14, 2024
Copy link
Member

@joemcgill joemcgill left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think these are both really good suggestions. That said, I think it may be premature to add these optimizations to the plugin. Right now, I think we should be focusing on collecting the impact data of the speculation rules in the field both in terms of how it improves CWV scores for sites that have it enabled, and also what impact the API has on hosting resources when it is in use, so we have a good understanding of what defaults should potentially ship in a future WordPress release. If we implement these two optimizations, I'd want it to be based on real data or user feedback rather than theory.

For the logged in user optimization specifically, the same issues with uncached requests also occur for non-logged in users on many sites so I'm not sure we should just be solving that problem specifically for non-logged in users and we're probably more likely to get user feedback from logged in users so maybe better just to document some common optimizations like this that are optional, or else add some settings for speculations rules that includes disabling for logged in users.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Plugin] Speculative Loading Issues for the Speculative Loading plugin (formerly Speculation Rules) [Type] Enhancement A suggestion for improvement of an existing feature
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants