Blocks: allow enqueueing frontend js files with custom loading strategies

[jeherve]

Since WordPress 6.3, one can enqueue scripts on the frontend of a WordPress site while defining defer or async:
https://make.wordpress.org/core/2023/07/14/registering-scripts-with-async-and-defer-attributes-in-wordpress-6-3/

We currently leverage this for some of our scripts, but not for any of the scripts enqueued alongside blocks:

jetpack/projects/plugins/jetpack/class.jetpack-gutenberg.php

Line 604 in 46e8a18

wp_enqueue_script( 'jetpack-block-' . $type, $view_script, $script_dependencies, $script_version, false );

It would be nice to add that option there. Maybe this is something that should be passed on block registration, in Blocks::jetpack_register_block()?

---

Related conversation: #44532

the JS for the Subscribe block is a non-defer classic script:

[jeherve]

@Automattic/heart-of-gold Is this something you'd be interested in taking on?

[westonruter]

Passing false as the $in_footer arg is also problematic because it makes this blocking script also render blocking. Do these scripts need to be in the head? If not, at least passing true for that arg will prevent it from being render-blocking. But now that $in_footer arg can be even better as:

array(
    'in_footer' => true,
    'strategy'  => 'defer',
)

This presumes the JS in the script can run after the DOM has loaded.

[jeherve]

Do these scripts need to be in the head?

I don't know that we can assume anything, since many of our blocks output js on the frontend, and they don't all work the same way.

That's why I would rather have this being set as the block is being registered. Maybe defer can be the default though!

[kraftbj]

Unassigning myself to reflect it is open for someone else on the team to take, but it's part of our current cycle.