-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use defer loading strategy for frontend view scripts #52536
Changes from 25 commits
7e469ec
23b7aad
aefd67a
f89e31a
3dd37c2
4f7301b
3e7c73e
34faf8f
5329284
2bafd37
4b86ce4
95beb24
404128f
4ccd709
b7863e9
c41d35b
b50a2b8
a18d055
712c4cf
b2db932
4a7fc46
7fe5534
ffd9e5c
26c06ab
86b8e36
aab0b4b
73e3564
da2380a
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -7,20 +7,21 @@ | |
*/ | ||
|
||
/** | ||
* Move interactive scripts to the footer. This is a temporary measure to make | ||
* it work with `wp_store` and it should be replaced with deferred scripts or | ||
* modules. | ||
* Move interactive scripts to the footer and make them load with the defer strategy. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. do they still need to be in the footer if deferred? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. +1, arguably having them in the header would have a small benefit of allowing early discovery. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Oh, I suppose what is meant by the original What I'm also curious about with the Interactivity API is whether it can load in the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hey, this is awesome!! 🙂
Exactly. But as array(
"in_footer" => false,
"strategy" => "defer"
)
The problem I see with But I reckon that even if not likely, the UX of tapping on a menu/search and not getting any response is bad and I've always wanted to solve it. What we could do with the Interactivity API is to use event delegation to capture all events prior to the hydration and retrigger them once the blocks are hydrated. That would mean no blocking whatsoever of the DOM load and still being responsive to events. Qwik is basing all his code-splitting on this concept, so I guess it's doable, although for me, a way to inform the user that the event was captured and it's awaiting execution is still missing to make the pattern fully functional. |
||
* This ensures they work with `wp_store`. | ||
*/ | ||
function gutenberg_interactivity_move_interactive_scripts_to_the_footer() { | ||
// Move the @wordpress/interactivity package to the footer. | ||
wp_script_add_data( 'wp-interactivity', 'group', 1 ); | ||
wp_script_add_data( 'wp-interactivity', 'strategy', 'defer' ); | ||
|
||
// Move all the view scripts of the interactive blocks to the footer. | ||
$registered_blocks = \WP_Block_Type_Registry::get_instance()->get_all_registered(); | ||
foreach ( array_values( $registered_blocks ) as $block ) { | ||
if ( isset( $block->supports['interactivity'] ) && $block->supports['interactivity'] ) { | ||
foreach ( $block->view_script_handles as $handle ) { | ||
wp_script_add_data( $handle, 'group', 1 ); | ||
wp_script_add_data( $handle, 'strategy', 'defer' ); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I guess that if we are making all frontend block scripts deferred by default, we don't need to do it for the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Cool. Done in aab0b4b |
||
} | ||
} | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@westonruter, do we have a patch against WordPress core that sets the default strategy for
viewScripts
todefer
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm catching up after an extended leave, so I might find the answer myself in the meantime as I'm reading the communication related to the
defer
strategy. I'm mostly willing to ensure we have better defaults in WP core, so people have performant configuration by design.At the moment, I don't see any changes applied in core:
https://github.com/WordPress/wordpress-develop/blob/f107073f39827c2ab2b3b3198e194f844f357213/src/wp-includes/blocks.php#L169-L174
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The patch hasn't been backported to core yet. I wasn't sure when that should be done, if it should sit in Gutenberg a bit first to test and then propose for core, or to add it to core at the same time. I'm happy to open a backport ticket and open a PR to apply this patch.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Opened Core-59115 and WordPress/wordpress-develop#5019
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Committed to core: r56398
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's enable it for all blocks in both the Gutenberg plugin, and in WordPress core to get as much testing as necessary with 3rd party blocks that use
block.json
. I see that you discussed it in the context of view scripts in #52536 (comment) and ruled out as a potential issue.Noting that with this patch,
defer
is going to be used witheditorScript
,script
, andviewScript
. In the case ofeditorScript
, the dependencies aren't usingdefer
likewp-block
orwp-block-editor
so it will probably fallback to the legacy handling. I'll comment on Trac, too.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, it should be enabled for all blocks, whether core or 3rd party.
Oh, good catch!