[wp-trac] [WordPress Trac] #59301: Incorporate script loading strategies in WP Admin to improve performance where applicable

[WordPress Trac]

#59301: Incorporate script loading strategies in WP Admin to improve performance
where applicable
-------------------------------------+-------------------------------------
 Reporter:  westonruter              |       Owner:  adamsilverstein
     Type:  enhancement              |      Status:  assigned
 Priority:  normal                   |   Milestone:  Future Release
Component:  Administration           |     Version:  6.3
 Severity:  normal                   |  Resolution:
 Keywords:  good-first-bug needs-    |     Focuses:  javascript,
  patch                              |  performance
-------------------------------------+-------------------------------------
Changes (by SirLouen):

 * keywords:  good-first-bug => good-first-bug needs-patch


Comment:

 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:

 Before:
 [[Image(https://i.imgur.com/SVB1WUh.png)]]

 After:
 [[Image(https://i.imgur.com/DPrqphV.png)]]

 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.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/59301#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform