[wp-trac] [WordPress Trac] #12009: Add support for HTML 5 "async" and "defer" attributes

[WordPress Trac]

#12009: Add support for HTML 5 "async" and "defer" attributes
-------------------------------------------------+-------------------------
 Reporter:  Otto42                               |       Owner:  10upsimon
     Type:  enhancement                          |      Status:  assigned
 Priority:  high                                 |   Milestone:  6.3
Component:  Script Loader                        |     Version:  4.6
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-unit-tests 2nd-        |     Focuses:
  opinion                                        |  performance
-------------------------------------------------+-------------------------

Comment (by azaozz):

 Replying to [comment:104 joemcgill]:
 > another important consideration for this proposal is that the Script
 loader also serves as the common API (along with helper functions like
 `wp_register_script` and `wp_enqueue_script`) for developers to use to
 ensure scripts are included in the HTML that WP generates.

 True. However it doesn't make sense to use that API just to output a
 `<script>` tag imho, i.e. waste a bit of resources "just because why not"
 :)

 If this is added to Script loader I think there should be a nice, long
 explanation in the docs that such use is "not recommended" and a "bad
 practice" as it only uses a little bit of resources without providing any
 benefits. However I agree it would be better to support that, even only
 for completeness.

 > The current approach taken in [https://github.com/WordPress/wordpress-
 develop/pull/4391#issuecomment-1538572942 PR 4391] tries to resolve
 potential load order conflicts when `async` scripts have dependencies by
 forcing them to be loaded with a `defer` or blocking strategy (whichever
 is appropriate).

 Yea, that's a good question. According to this it seems `async` scripts
 used as a dependency should be loaded as "blocking" (that's the behavior
 when the script is cached in the browser).

 This effectively "bans" use of scripts with `async` when they use the
 capabilities of Script loader.

 > However, as @westonruter has pointed out, it may not make sense for WP
 to try to control loading order for `async` scripts in this way, given
 that ''by definition'' the loading order of `async` scripts is
 unpredictable and should be accounted for by developers choosing to use
 this strategy. In other words, `async` scripts absolutely can have
 dependencies, they just need to account for the `async` loading nature of
 such scripts.

 Yep, that makes sense too. In this case `async` scripts will always be
 treated as "stand alone" and excluded from calculating any dependencies.

 > The question I'd like to get consensus on is whether we keep the current
 approach, which attempts to resolve loading order conflicts (more
 forgiving of developer mistakes) or if we should trust developers to take
 responsibility for using `async` scripts as designed and allow `async`
 scripts to have other dependencies that are `async`.

 Generally `async` scripts can be treated as "blocking", as that's their
 behaviour when cached. Also both `async` and `defer` scripts can have
 "blocking" dependencies (that will be loaded earlier).

 However there haven't been any examples of websites that use `async`
 scripts as dependencies. My biggest problem with the current approach is
 exactly this: it tries to implement theoretical use cases without any
 evidence any of them would ever be useful.

 > Personally, I'm finding @westonruter's rationale for allowing developers
 to use `async` scripts as dependencies and trusting them to do so
 responsibly fairly convincing. If we can agree there, then we can address
 additional edge cases and nuances.

 Yea, shifting the decisions to plugin/theme developers seem to make sense
 here (assuming good inline docs). After all the use cases for `async` are
 few and far between compared with the cases for `defer`. What I'm
 uncomfortable about are the possible edge cases and nuances. Seems
 addressing them would add quite a bit of code, and generally make Script
 loader slower and more complex for a very minimal, if any benefits. Again,
 imho this would depend on providing (and studying) examples of actual
 sites that use `async` scripts as dependencies or dependents.

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