[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 flixos90):

 Replying to [comment:95 joemcgill]:
 > **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.

 Agreed :)

 > **Reconsider changing the registered loading strategy for `async` and
 `defer` scripts based on their dependents**
 >
 > [...]
 >
 > 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.

 After our conversation earlier on Slack, I feel more inclined towards
 leaving responsibility for scripts marked `async` to the developers doing
 so. However, I think that is a topic separate from "Reconsider changing
 the registered loading strategy for `async` and `defer` scripts based on
 their dependents", those are two things:
 1. One point is to potentially fall back to another strategy for an
 `async` script if e.g. a blocking script depends on it.
 2. Another point is to allow dependencies for `async` scripts at all.

 For the first point, my take based on our conversation earlier is that we
 should still allow for an `async` script to fall back to blocking if
 needed, since that would ensure a load order that satisfies all scripts in
 the dependency chain: The `async` scripts basically don't care ''when''
 they load, so it doesn't matter that the one `async` script becomes
 blocking in terms of load order, while for the blocking script it is
 imperative that the dependency is also blocking so that it is loaded
 before. Something to consider here though is that an `async` script should
 potentially only be eligible to fall back to blocking, but not to a
 `defer` strategy since in that case it would be possible for the script to
 be loaded at a later point than before.

 For the second point, I now agree that for scripts added with `async` we
 can allow dependencies (as already hinted by my example to explain the
 first point). We still have to clearly explain the considerations for
 doing so, but from my current understanding any load order problems from
 declaring a script `async` will apply to that script itself, not other
 blocking or deferred scripts that depend on it. So it's reasonable to
 allow `async` dependencies as that won't break ''other'' people's code.
 That said, I'd like to re-emphasize that `defer` should be encouraged and
 `async` needs to be clearly explained on what requirements it has to the
 scripts that use it.

 > **Address CSP concerns with managing inline scripts printed after
 dependencies**
 >
 > [...]
 >
 > 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.

 I think we should go with option 3, but only for `defer` scripts, as that
 will allow us to address the CSP concerns (by using a `load` event
 listener instead of `onload` attribute) while allowing scripts with inline
 scripts to be deferred still, which is a crucial piece to adoption of the
 new strategies. Based on our chat earlier today, this approach is
 technically not reliable for `async` scripts, and not supporting inline
 scripts for `async` scripts is a reasonable trade-off to me (due to their
 less common use case).

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