[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:97 azaozz]:
 > 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.

 I think it's a bit more nuanced than that. They cannot be used as a
 dependency when it comes to load order, however they can still be used as
 a dependency in that they need to be loaded at all (i.e. "make sure to
 load these dependencies" vs "make sure to load these dependencies
 ''before'' the main script"). They can always be used as a dependent
 though, i.e. depending on other scripts. An `async` script could certainly
 rely on a blocking script. So I think there's a benefit in supporting
 `async`, though we still have to identify how to handle its different
 implications and how much responsibility for "doing things right" we
 should leave to the developer using the strategy.

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

 "cleaner and easier" is relative :) As I mention above, the one part that
 manual handling of `async` is missing out on is dependency management,
 which still is relevant even for `async` scripts. The original proposal we
 had was to not allow dependencies for `async` scripts (in which case I
 would have agreed with you) but based on the latest feedback shared by
 @westonruter that may not have been the right approach.

 > 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'm not sure how "hacky" it is. In the way outlined (including addressing
 the CSP concerns) it only involves using a simple inline script to ensure
 correct load order. Note that it would probably only be for `defer`
 scripts regardless of `async` support since it wouldn't be reliably
 possible for `async` scripts anyway without violating CSP.

 Also note that not doing the `text/template` approach doesn't mean `defer`
 scripts couldn't support "after" inline scripts at all. They still could,
 though at that point it would be on the developer to ensure the "after"
 script is written in a way that works even though its main script is
 deferred. Not automatically ensuring an "after" script works is one thing,
 but not supporting it at all would be a notable loss for adoption, since
 there would not even be a migration path for scripts with "after" scripts;
 if we still support it but don't do the `text/template` handling, we can
 document how an "after" script's code has to be written if it is used on a
 deferred main script (e.g. wrap it in a `load` event listener for the main
 script).

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

 That's a fair point, and I think it's worth quantifying that to make an
 informed decision. Right now, I believe that is simply a guess - a guess
 that I would share, but it's still a guess :)

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