Use defer loading strategy for wp-embed script and move to head in block themes

[westonruter]

The wp-embed script is printed to the page if there are any post embeds present. The script is registered to be printed in the footer. However, now that core has support for script loading strategies (#12009), this can be revisited. In #58870 the async strategy was added to the comment-reply script while keeping the script in the footer: this is because the script is very low priority and only needs to load after the user has scrolled down to the comments. For wp-embed, however, the situation is different. There may very well be post embeds appearing near the top of the page. Therefore it is important for wp-embed to run as soon as possible. This can be achieved by moving the script to the head and adding the defer loading strategy. In this way, the browser will discover it early to start loading but wait to execute until the DOM has loaded, similar to when it executes today in the footer. This was recently done in ​gutenberg#52536 where all block view scripts were given the defer strategy.

For classic themes the wp-embed script and block view scripts would continue to be loaded in the footer since the blocks are processed after wp_head has finished. Block themes on the other hand would be able to take advantage of this early-loaded yet deferred wp-embed script like other block view scripts.

• Add defer loading strategy to wp-embed.
• Remove footer group from wp-embed so it can start loading in the head in block themes.
• Remove obsolete load event handler in wp-embed since IE10+ support DOMContentLoaded.

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

We might want to consider removing this code given that IE11 is no longer supported:

​https://github.com/WordPress/wordpress-develop/blob/512b267fec46a9207355148ec9ea4ddd663298af/src/js/_enqueues/wp/embed.js#L101-L102

​https://github.com/WordPress/wordpress-develop/blob/512b267fec46a9207355148ec9ea4ddd663298af/src/js/_enqueues/wp/embed.js#L118-L123

[westonruter]

I made 100 requests using ​benchmark-web-vitals, both before and after the change. I tested on the wordpress-develop development environment in TT3 on a post that had a single post embed from Make/Core and comments open. Here is the median impact to LCP-TTFB that I observed:

Before: 49.45 ms
After: 50.85 ms

Surprisingly, it actually increased LCP by 1.4 ms. Nevertheless, since I'm testing on my local machine when there is no network latency, this may be the cause. If there are network constraints it stands to reason that it would take more of a percentage of the loading time, and then defer would help.

This was with the post embed appearing in the first viewport, however. The network variability of loading the post embed may be to blame.

If I modify the post to add various paragraphs above the post embed so that it is pushed out of the initial viewport, the LCP-TTFB results are as follows:

Before: 54.2 ms
After: 52.95 ms

Here the LCP decreased by 1.25 ms.

All in all, the impact of this change seems like it will be marginal in either direction.

Lastly, I did try modifying the benchmark-web-vitals command to ​emulateNetworkConditions for Slow 3G, still with the post embed outside the viewport. Over 25 requests, the median LCP-TTFB I observed:

Before: 3043.3 ms
After: 3041.3 ms

So again, the difference is a miniscule 2 ms.

Nevertheless, the performance impact is negligible: https://core.trac.wordpress.org/ticket/58931#comment:3

@felixarntz how about removing the obsolete IE code mentioned in ​https://github.com/WordPress/wordpress-develop/pull/4928#issuecomment-1656420738?

@westonruter That sounds good to me!

[westonruter]

In 56355:

Script Loader: Use defer loading strategy for wp-embed script and move to head (in block themes).

Props westonruter, flixos90, swissspidy.
Fixes #58931.

Committed: ​https://github.com/WordPress/wordpress-develop/commit/1fc10c92a273996903fbdd5e0c2a493875a53bd2