Incorporate script loading strategies in WP Admin to improve performance where applicable

[westonruter]

As of #12009 the script loader now has the ability for scripts to be printed with async or defer. This is being used on the frontend now for block view scripts (#59115), the comment-reply script (#58870), and the wp-embed script (#58931). Nevertheless, these new script loading strategies are not currently being used in the admin. There may be opportunities to improve performance by doing so.

Typically only jquery-core, jquery-migrate, and utils (less frequently moxiejs and plupload, and even less frequently wp-polyfill-inert, regenerator-runtime, wp-polyfill, wp-hooks, zxcvbn-async, wp-codemirror, and underscore) are loaded in the head in the admin; furthermore, these scripts are concatenated together via load-scripts.php. For backwards-compatibility, these scripts might not be able to be delayed or moved to the footer. In other cases, there may be existing footer scripts that could be moved to the head and made to load with defer: this would ensure that they start loading sooner so that they can execute as soon as the document finishes loading. Other scripts could potentially be lazy-loaded only when needed (e.g. zxcvbn).

Note that the block/site editor screens will benefit the most from ​block lazy loading.

[tabrisrp]

Is there already some steps that were discussed for this?

[westonruter]

Replying to tabrisrp:

Is there already some steps that were discussed for this?

Steps in what way? Like specific scenarios which were identified in the admin where async/defer scripts would improve performance? No.

[SirLouen]

Amazed to see the full Google crew on the same ticket. But I'm not sure if this is a good-first-bug candidate (just wondering why no one put a foot in almost 2 years, this is an interesting ticket that requires extensive analysis and somewhat complex to identify dependencies to best select async instead of defer and preserve loading order without conflicts).

In fact, I would say that this should be more a blessed task than a singular enhancement because many interactions should be done to get to a quality result in this same ticket (and for different admin areas, dashboard, post editor,...)

This said, some ideas for anyone willing to start working on this:

Reproduction and Working Steps

1. For any user willing to take this (or a part of this), my recommendation: You don't need to (and you should not) submit the whole patch with full optimizations. With just 1, 2 or 3 proven optimizations, it will be enough to submit a patch that can be committed individually. The more optimizations in one patch, the more is going to take to be evaluated, hence, committed.

2. Start adding just one defer to one of the last loading scripts (check script loading order in and test performance improvement). Keep doing this in backward order until you have deferred in order all the scripts without breaking the admin area.

3. Then try to figure out, which scripts don't have any dependencies from the deferred list and try to async them instead. Keep checking performance every change.

4. For performance checking, personally I like to purposely hinder the browser to get big consistent numbers in seconds rather than fast decimals that tend to have too much variation. For example, hindering CPU to 4x slowdown and working on Slow 4G is sufficient in most cases as you will quickly get anything over 10 seconds LCP where you will clearly see the effects of this performance tweaks.

5. Testing is equally complicated; hence, ideally, once should start from the scripts at the bottom of the waterfall. I just took one random script that I've checked that it's an end-script without dependencies, but it's safer to start with the last ones that should not have dependencies for obvious reasons, in this case, some script like autocomplete.js

For example, with these parameters, deferring dashboard.js as the patch I've submitted, we can see that it's no longer render blocking, but it is not necessarily going to improve performance much (or at all), at least in this case, so maybe we should consider if leaving it or just ignoring.

Before:

After:

Finally, I'm wondering to which extent, old browsers should be respected in this regard and use strategy => defer instead of in_footer => true, which is much orderly. Personally, I don't know which policy is taking WP in regard of this topic.

PS: Located this little dependency issue while testing #63432, so this also seems a good debugging exercise.

This is a proof of concept to move the needle a little on ticket 59301.

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