[Experiment] Full-page navigations using Speculation Rules #60959
Conversation
michalczaplinski
added
[Type] Technical Prototype
| // add the listener for when the user leaves the page | ||
| window.addEventListener( 'beforeunload', storeStore ); |
There was a problem hiding this comment.
As opposed to only updating the store when the user unloads the page, what if it is consistently updated throughout the life of the page? Imagine then if you had two windows open side-by-side. As you make changes in one window, you could then see them update in the other window. Naturally this would involve adding a storage event and not just a prerenderingchange. And performance would need to be protected against, given that sessionStorage is a synchronous API. Also, this could be annoying to a user as it could very well be that they want the state to differ between two windows (e.g. comparing flights for two different vacation options).
There was a problem hiding this comment.
Right :)
I'm becoming more convinced that we might want to offer a separate "MPA mode" and "SPA mode" for full-page navigations.
- The MPA mode would use the Speculation Rules and just prerender another page. When doing a navigation, the client-side state is lost.
- The SPA mode is what's implemented in Experiment: Add full page client-side navigation experiment setting #59707.
It might even be possible to mix and match the two modes on the same site. So you can imagine that navigating around product pages in an e-commerce site uses SPA mode, but then navigating to the "about us" or "shipping rates" pages uses the MPA mode.
There was a problem hiding this comment.
If the client-side state is preserved in MPA mode (e.g. using some approach as in this PR), would there then need to be an SPA mode?
There was a problem hiding this comment.
It might be tough to reliably preserve the client-side state in MPA mode. The current PR does it for the state from the store but we would need to do the same for context and getElement(). (link).
Perhaps there might be some way to expose the context in the Interactivity API and let the framework merge it upon navigation. That would need quite a bit of work though 😄 .
That said, choosing between SPA and MPA for navigation in an application is an architectural decision. So, we can't slap SPA navigation on a site that assumes it was built for MPA or vice versa. Because of this, even if preserving all client-side state (state, context & element) can be done, we would still need the user to decide between SPA mode and MPA mode.
To prefetch or to prerender eagerly? Note that in prefetch no JS is executed on the page as only the HTML is fetched and cached. Beware that if you have more than 10 links on the page then those after 10 won't get prerendered, at least in Chrome's limits. The moderate eagerness (e.g. activate on hover) I think is preferable to the eager eagerness (e.g. activated on the first 10 links on the page right away). |
Right! I meant "prerender", thanks for catching this.
Totally, makes sense. I only meant that for testing this PR it's easier to crank up the eagerness so that you the pages prerender as soon as you load the initial page so you don't have to hover manually 🙂 . |
What?
Trying to leverage the Speculation Rules API (https://make.wordpress.org/core/2024/04/09/speculative-loading-in-wordpress/#comment-46576) to do full-page navigations using the Interactivity API.
Testing Instructions
You'll need to: