Implement speculative loading of the search form

[westonruter]

Summary

Fixes #1291

This speeds up searches by doing speculative loading of the search results page when the user has entered a search query and is signaling they are about to perform a search.

Here's a test site with this patched version of the plugin installed: https://speculative-loading-test.instawp.xyz/search/

Screen.recording.2024-06-11.03.22.30.webm

(Note the TTFB of 0 ms. This was recorded on airplane wifi!)

Relevant technical choices

The Interactivity API is leveraged to listen for events which signal that a pending search has been entered, namely on the change event as well as whenever a submit button gets a focus event or pointerover. Additionally, when hitting Enter in the search input field it will start to speculatively-load at keydown which could in theory save a few milliseconds. (Alternatively to this, a debounced input event may make more sense.)

The HTML Tag Processor is used to inject the Interactivity API directives on the search form, both in the Search block variant as well as in the classic variant returned by get_search_form().

It seems the key is how the form submit event is handled. If the default form submission handling is done, then the speculative prerender is not reused. However, if the submit event handler does preventDefault and then manually navigates to the URL that the search submission was going to go to anyway, then it works!

performance/plugins/speculation-rules/search-form.js

Lines 65 to 72 in d45eb1c

	handleFormSubmit: ( event ) => {
	event.preventDefault();
	const form = event.target;
	const formData = new FormData( form );
	const url = new URL( form.action );
	url.search = new URLSearchParams( formData ).toString();
	location.href = url.href;
	},

This seems like a hacky workaround for something the browser should be doing automatically for GET form submissions.

[westonruter]

An action calling another action. Is this bad?

[luisherranz]

That's fine. Even expected 🙂

[westonruter]

See wp_interactivity_data_wp_context() which has a $store_namepace argument. The logic in that function could be replicated here. However, it seems this would conflict when there is already a data-wp-context attribute present.

[luisherranz]

I have created a discussion to see how we can solve that problem in a general way for all the directives:

• Differentiating between suffixes and unique-ids in the directive names gutenberg#62720