[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:95 joemcgill]:

 > 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

 +1.

 I still don't see why (and how) async scripts can be handled through
 script-loader. As I said earlier, they cannot be used as a dependency and
 cannot be dependent on other scripts because of the unknown execution
 order.

 It would be much cleaner and easier if themes and plugins output these
 scripts themselves at the appropriate `wp_print_scripts` action. There
 they can also handle any before/after scripts, etc.

 > 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.

 Yea, printing inline scripts with `text/template` type seems pretty
 "hacky" imho. Lets avoid that even if it means that `defer` scripts will
 not support "after" scripts (`async` scripts shouldn't be in the script-
 loader at all imho, see above).

 > 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.

 Thinking 1 makes most sense. Keep in mind that "after" scripts are
 relatively rarely used. So disallowing them for `defer` scripts would
 probably not be a problem for the great majority of plugins and themes.

 Another possibility is to implement the "after" script in the `defer` or
 `async` script itself. I.e. when the script is being executed it can look
 for "external" object or function or data and use it when appropriate.
 That would be the "proper way" imho.

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