[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
-------------------------------------------------+-------------------------
Changes (by joemcgill):

 * keywords:  has-patch has-unit-tests => has-patch has-unit-tests 2nd-
               opinion


Comment:

 Thank you to everyone who has provided such useful feedback to
 [https://github.com/WordPress/wordpress-develop/pull/4391 PR #4391].
 @10upsimon and I are currently reviewing this feedback and will be
 updating the PR in response to the feedback we've gotten thus far.

 Of the feedback we've received, there are a few larger proposals that
 warrant additional conversation before we move forward.

 **Update `WP_Scripts` to make use of `wp_get_inline_script_tag()` and
 `wp_get_script_tag()` when constructing script tags**

 This seems like a natural enhancement to me, and given that @westonruter
 has already [https://github.com/10up/wordpress-develop/pull/58 drafted a
 PR] to implement this change, I see no reason not to move forward with
 this approach.

 **Reconsider changing the registered loading strategy for `async` and
 `defer` scripts based on their dependents**

 The current approach was taken with maintaining the execution order of
 scripts in the dependency tree as a top priority. As a simplified example,
 this means that if `script-1` is registered with a `defer` strategy, and
 `script-2` is registered with a `blocking` strategy (or none at all) but
 it depends on `script-1`, then WordPress would ensure that `script-1` will
 also be enqueued with a blocking strategy. A similar approach is taken for
 `async` scripts.

 For `defer` scripts, this approach probably makes sense. However, for
 `async` scripts, there is a valid argument to be made that anyone
 registering a script as `async`, or as a dependency of an `async` script
 should be responsible for anticipating the unknown execution order of an
 async script and handle that logic themselves, rather than WordPress
 trying to resolve conflicts on their behalf. For more,
 [https://github.com/WordPress/wordpress-
 develop/pull/4391/files#r1179857620 see this conversation on the PR]. I'd
 appreciate additional opinions what WordPress' responsibility should be in
 this case.

 **Address CSP concerns with managing inline scripts printed after
 dependencies**

 In order to maintain execution order for inline scripts attached to
 `defer` and `async` scripts, we've attempted to control the loading order
 of those inline scripts by printing them with the type `text/template` so
 they're not initially executed, and then executing them after the script
 they're attached to has loaded. @westonruter added
 [https://github.com/WordPress/wordpress-
 develop/pull/4391#issuecomment-1536869109 a great explanation] about how
 this can lead to subtle CSP issues that we need to address.

 However, as @azaozz suggested above, perhaps we should either not support
 printing inline scripts after non-blocking scripts at all, or resolve
 loading order conflicts by forcing a script to be enqueued with a blocking
 strategy if an inline script is attached that should be printed after. I'd
 appreciate feedback on these three options:

 1. WP should not support inline scripts printed after a script that is
 `async` or `defer`.
 2. WP should load non-blocking scripts with a blocking strategy if an
 inline script is registered with the `after` position.
 3. WP should allow inline scripts after non-blocking scripts, but should
 ensure the inline script is not executed until after the script it is
 attached to has loaded (i.e., the current approach) and address CSP
 concerns.

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