Support for lazy hydration techniques: idle and view

[luisherranz]

It'd be great to delay the hydration of some of the interactive blocks to improve the time-to-interactive metrics of the site.

Hydrating on idle (CPU), when the block is about to enter the viewport, or only on certain screen sizes (media query) are techniques already used by frameworks like Astro. Rocket's implementation is also interesting. And we also implemented similar patterns in previous interactivity experiments.

Naming

"Hydration" is not a common term in WordPress, so my suggestion is to use "load" instead and refer to it as block loading techniques.

Configuring the loading technique

Maybe we could leverage the data-wp-interactive directive for this:

<div data-wp-interactive='{ "load": "idle" }'>...</div>

<div data-wp-interactive='{ "load": "view" }'>...</div>

Block developers could use the block.json "interactive" field to add this information (which then will be added automatically to the data-wp-interactive directive):

// block.json
{
  "interactive": {
    // other options...
    "load": "idle"
  }
}

If they have options, "load" could accept an object:

// block.json
{
  "interactive": {
    "load": {
      "view": {
        "rootMargin": "0px"
      }
    }
  }
}

Combining techniques

Blocks could configure multiple loading techniques and the block would be hydrated when one of them triggers:

<div data-wp-interactive='{ "load": { "view": true, "idle": true } }'>...</div>

Code-split loading techniques

Ideally, we should code-split the code of each loading technique so we don't enqueue unnecessary JS.

<div data-wp-interactive='{ "load": "idle" }'>...</div>

• This enqueues the loading-idle.js file

<div data-wp-interactive='{ "load": "view" }'>...</div>

• This enqueues the loading-view.js file

The core runtime should only take care of hydrating the islands that don't have any special needs and don't do anything for the rest. Then, each loading technique file could take care of hydrating its own islands.

Download of scripts

Script download and execution should also be delayed. That means that for each lazy-loaded block, we should:

• Dequeue its scripts and replace them with a link preload/prefetch (or modulepreload if we finally use modules).
• Add its scripts to the DOM once the hydration is triggered.

This means we need to know the source (or sources) of the scripts required by each block. We could also leverage data-wp-interactive for that:

<div data-wp-interactive='{ "load": "view", "script": "https://.../view.js" }'>
  ...
</div>

Having the scripts required for each block clearly stated in the HTML may also help when loading them for full-page client-side navigation.

Alternatively, we could use the enqueue ids instead of the URLs.

The order of execution would be something like this:

• The hydration event was triggered for a specific block.
• The hydration runtime adds its scripts to the DOM and waits until they have finished executing.
• The hydration runtime hydrates the block: runs toVdom and passes the result to Preact's render.
• The hydration runtime marks the block as hydrated, so nobody tries to hydrate that block again.

Parent-child relationship

We need to decide if a child who wants to be hydrated before the parent should force the parent hydration, or if the first parent hydration technique should be enforced among all its children.

For example, imagine a child that wants to be hydrated before a parent because it's set to hydrate on idle whereas the parent block is set to hydrate on view:

<div class="parent-block" data-wp-interactive='{ "load": "view" }'>
  <div class="children-block" data-wp-interactive='{ "load": "idle" }'>...</div>
</div>

My initial thought about this is that it's safer to force the parent hydration, but it may also lead to bad performance when a single child can force its parent and all siblings to hydrate.

If we decide that the parent should be forced to hydrate, we should do something like this:

// Hydration was triggered!
const parent = node.closest("[data-interactive],[data-ignore]");
if (parent.getAttribute("data-ignore")) {
  // This node is isolated from the rest, it can be hydrated on its own.
  hydrateAlone();
} else {
  // Force the parent hydration.
  forceParentHydration(); // This logic should be repeated to find its own interactive parent.
}

And if we decide that the parent should not be forced to hydrate, we should do something like this:

// Hydration was triggered!
const parent = node.closest("[data-interactive],[data-ignore]");
if (parent.getAttribute("data-ignore")) {
  // This node is isolated from the rest, it can be hydrated on its own.
  hydrateAlone();
} else {
  // This has a parent, so don't do anything. It will be hydrated once the parent is.
}

Behaviors

Behaviors could also define their loading technique, and those should be accumulative.

Behaviors don't have a JSON yet, so this is just an example of how this could work in the future.

// Image Lightbox - behavior.json
{
  "load": "view"
}

// Image Zoom on hover - behavior.json
{
  "load": "idle"
}

<!-- Resulting HTML of the Image block when both behaviors are active -->
<figure data-wp-interactive='{ "load": { "view": true, "idle": true } }' ...>
  <img ... />
</figure>

Available Techniques

I would probably start with idle and view, but other interesting ones could be developed in the future. Here is a tentative list:

• Idle:

  Load when the CPU is idle (requestIdleCallback).

  This is useful to avoid blocking the initial load of the page, and for blocks that will likely be used but are not critical.

• View:

  Load when the element enters the viewport.

  One possible use case is to avoid loading the Comments Reply logic until the user is scrolling down and about to reach the comments.

  Possible options are the Intersection Observer options, like rootMargin.

• Media:

  Load only on certain media queries.

  One possible use case is to avoid hydrating the Navigation block when the overlay menu is on "mobile" and it doesn't have submenus, and the user visits the page on a desktop computer.

  It needs a required query option, like (max-width: 789px). Alternative names could be used to allow for preconfigured media queries, like "load": "mobile" or "load": "desktop".

• Hover:

  Load when the user hovers over the element.

  One possible use case is to avoid loading the Image Lightbox behavior until the user is hovering over an image.

Loading techniques on full-page client-side navigation

Preact doesn't support upgrading from partially hydrated islands to a fully hydrated page yet (even with hacks) because changing the number of parent components in a tree after the initial hydration removes the children and adds them again unnecessarily. That means that the logic can't be reused, at least for now, when full-page client-side navigation is enabled, and therefore we need to take that into account when implementing each of the different parts.

[luisherranz]

Oh, I forgot one thing.

Third-party store dependency

Maybe a third-party block requires the store of another block (namespace) which is lazy load and therefore may not be present from the beginning.

Imagine a coolCommerce block that has an embedded cart that only loads when an overlay menu is open, but its store contains an add to cart action (actions.coolCommerce.addToCart). The third-party block may need to access the addToCart action before the user has opened the overlay.

This is a tricky one because declaring a dependency on another block will fail if the block is not present on that page and declaring a dependency on another's block script will fail if the block owner refactores their files.

I'll think about that 🙂

[luisherranz]

There is a solution to this problem in the new store() API proposal:

• New Interactivity `store()` API proposal #53586

[Saoming]

I like the idea of how Astro did it. Would be cool if we can put media under the load JSON.

In the future, Is it also possible to control CSS / stylesheet that is attached to the block as well?
Instead of js or with stylesheet inside data-wp-interactive.

[luisherranz]

Is it also possible to control CSS / stylesheet that is attached to the block as well?

Oh, it should be possible, yes. And it should not be difficult because we are already building something similar for the client-side navigations.

[luisherranz]

We also hit this problem when trying to do region-based client-side navigation and the new region contains blocks that are not present on the previous page:

• Experiment: Comments block: client-side form submission #53737 (comment)

So we should definitely investigate that, and if we come up with a solution, use it here as well 🙂

[Saoming]

So Since Astro uses Island Architecture. Have you checked Marko JS and QWIK JS? It's interesting what QWIK does in terms of partial hydration. Since I have posted before I feel that moving into Preact is the wrong approach if we are looking forward to the future, especially with Hydrations when we use the term "Interactivity" API. As you mentioned before Preact doesn't support upgrading from partially hydrated islands to a fully hydrated page yet. Maybe we should look into another framework. Hope this makes sense...

https://markojs.com/
https://qwik.builder.io/

[luisherranz]

Yes, we looked into both Qwik and Marko. They are both very interesting projects. The idea of annotating the primitives in the HTML itself comes part from Alpine, part from Qwik. But Qwik code is highly coupled with the server logic and the bundler. There's no easy way to replicate that in WordPress. Also, even though it's interesting, it hasn't gotten much real usage yet. It's also not compatible with React at the level that Preact is (to share Edit components on certain situations) and it doesn't have a dom diffing algorithm (for client-side navigation).

Marko is also interesting, but it is highly coupled to their own templating system, which compiles down to JavaScript. It's also very coupled to their server logic which is also JavaScript. We would have to build a compiler of their syntax to PHP and replicate all the server logic. Also, remove/limit the parts of their templating system that accept JS because those can't run in PHP. On top of that, we researched the usage of a templating system similar to the one that Marko uses, but we concluded that it's not a good idea because your components become a kind of a "black box" that cannot be modified in PHP because it gets out of sync with the frontend JS components. On the other hand, by using the HTML itself as the source of truth (through the use of directives), PHP can keep applying changes to the HTML and those changes are honored in the frontend.

Sorry for the long and technical explanation, but I hope that helps to understand the limitations we showed in those frameworks/approaches 😄🙏

[westonruter]

I just opened #58225 after finding that hydration can currently cause a long task which can significantly impact page performance, especially on lower-powered devices. I have a proposed fix in #58227 to break up the init() function so that it yields to main between each node being hydrated. This could be improved yet further by hydrating only when the node is in view. What's to stop lazy-hydrating by default? It would be great if this were the established expectation before authors start creating interactive blocks.

[westonruter]

I've opened a PR to propose this: #58284

[westonruter]

While #58225 is landing in 6.5 to break up the long task caused by hydration, there are more opportunities to improve performance as noted above.

Just to highlight the current state, I tried creating a post with 100 images, each of which has click to expand enabled. With 6x CPU slowdown, a performance trace shows that these hydration tasks take about 1500 ms. This is wasteful because only one of the interactive blocks is even shown in the initial viewport, meaning only the first couple of the tasks shown on the left here are actually needed:

See trace: https://trace.cafe/t/YknWfeNwqV

The rest can be deferred, either for when the CPU is idle or when the interactive block is entering the viewport.

Aside: The current implementation of using setTimeout() in #58227 could be replaced with postTask() as it would avoid needless 4 ms gaps between tasks that comes with using setTimeout().

Does anyone currently have this on their radar to work on?

[gziolo]

I don't think anyone is looking into it at the moment. @DAreRodz, might be better suited to answer this question as he is trying to shape the list of planned tasks for WordPress 6.6.

Aside, if you have 100 images on the page with expand-on click enabled, it also means that the HTML will have very similar HTML code duplicated for every image, which is another opportunity for optimization.

[luisherranz]

it also means that the HTML will have very similar HTML code duplicated for every image

I already refactored the block to reuse the same HTML for the overlay for all the images 🙂

• Image block: refactor and remove data-wp-body #58835