Use defer loading strategy for block view scripts

[westonruter]

In ​gutenberg#52536, the defer loading strategy was used for all block view scripts. This ticket is to backport the Gutenberg change to core. Script loading strategies were introduced in #12009.

Currently block view scripts are registered without setting the $in_footer argument to true. For block themes, this means they will get printed in the head since the_content is processed before the wp_head action. For classic themes, however, the_content is processed after wp_head, resulting in the scripts being printed at wp_footer. Therefore, given that block view scripts have been printed in either the head or footer already, this means they can safely be made defer. Leaving them in the head is advantageous because it means the browser will discover these scripts earlier and start loading them with other page resources, but the presence of defer means that they will no longer block page rendering.

This was similarly done for the wp-embed script in #58931.

Trac ticket: https://core.trac.wordpress.org/ticket/59115

[westonruter]

I tested the performance of this change, over 100 page loads before/after using ​benchmark-web-vitals:

npm run research -- benchmark-web-vitals -u http://localhost:8889/2023/08/15/pdf-embed/ -n 100 -o csv

I did this on wordpress-develop with SCRIPT_DEBUG disabled and the Twenty Twenty-Three theme active. I added the Search block to the header, configured to be button only so that its JS file is added to the page. I also configured the Navigation block with dropdowns and responsive menu so that is JS also is included. Lastly, I added a file block with an embedded PDF so that its view JS file is included. The median results for LCP-TTFB:

Before	After	Diff (ms)	Diff (%)
50.5	47.2	-3.3	-6.53%

[westonruter]

In 56398:

Editor: Use defer loading strategy for block view scripts.

Props westonruter, joemcgill.
Fixes #59115.

Committed: ​https://github.com/WordPress/wordpress-develop/commit/5fab14051188f87335ed5efdf5e199cf8517149f

[gziolo]

Noting that with [56398], the defer strategy is going to be used with editorScript, script, and viewScript. In the case of editorScript, the dependencies aren't using defer like wp-block or wp-block-editor, so it will probably fall back to the legacy handling.

It might be fine as is, but we will have to watch whether 3rd party blocks encounter any issues. If the intention was to apply that only to viewScript then we need to add a check against $field_name in the code.

[westonruter]

Replying to gziolo:

Noting that with [56398], the defer strategy is going to be used with editorScript, script, and viewScript. In the case of editorScript, the dependencies aren't using defer like wp-block or wp-block-editor, so it will probably fall back to the legacy handling.

It might be fine as is, but we will have to watch whether 3rd party blocks encounter any issues. If the intention was to apply that only to viewScript then we need to add a check against $field_name in the code.

Good catch. It was intended to only apply to the viewScript. I'll open a new PR to fix.

Trac ticket: https://core.trac.wordpress.org/ticket/59115

Commit message:

Editor: Ensure defer loading strategy is only applied to a block's viewScript.

Amends [56398].
Props gziolo, westonruter.
Fixes #59115.

[westonruter]

@gziolo I opened a ​PR to address this, but I only see register_block_script_handle() getting called with the $field_name of viewScript, both in core and when using Genesis Blocks and my own ​Syntax-highlighting Code Block.

[gziolo]

It's very likely that both plugins don't use register_block_type with block.json that defines editorScript or script. It's the regular path when register_block_script_handle gets called. I can at least see that it's the case for Syntax-highlighting Code Blocks. Many plugins still manually enqueue the script that registers the block on the client.

[westonruter]

In 56403:

Editor: Ensure defer loading strategy is only applied to a block's viewScript.

Amends [56398].
Props gziolo, westonruter.
Fixes #59115.

Committed in r56403.