[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:111 joemcgill]:
 > @azaozz, it seems like the crux of your concern is not whether WP should
 support `async` scripts, but instead whether this should be part of the
 Script loader API or handled by some other means.

 Yes, that's one of the concerns. It is already "handled by some other
 means" in "over 3,000 plugins". So the question becomes more like: How
 many of these 3,000 plugins will switch to use Script Loader in the first
 year after support for async is introduced? Would it be considered a
 failure if less than 10% of them switch?

 > The Script loader reduces the amount of code developers need to use to
 print a script. If not using the Script loader, you’d have to manually
 print the `<script>` tag yourself at `wp_head` or `wp_footer`, which would
 mean there is no standard way to attach inline scripts.

 That's not exactly true :)

 There are the several hooks that can be used to fine-tune when scripts
 without dependencies are outputted/printed. Can also use different hook
 priorities if you want to print your scripts before or after the default
 scripts, etc.

 - `wp_print_scripts`,
 https://developer.wordpress.org/reference/hooks/wp_print_scripts/
 - `admin_print_scripts`,
 https://developer.wordpress.org/reference/hooks/admin_print_scripts/
 - `wp_print_footer_scripts`,
 https://developer.wordpress.org/reference/hooks/wp_print_footer_scripts/
 - `admin_print_footer_scripts`,
 https://developer.wordpress.org/reference/hooks/admin_print_footer_scripts/

 In addition there are more specific hooks for specific admin screens:
 - `admin_print_scripts-{$hook_suffix}`,
 https://developer.wordpress.org/reference/hooks/admin_print_scripts-
 hook_suffix/
 - `admin_print_footer_scripts-{$hook_suffix}`,
 https://developer.wordpress.org/reference/hooks
 /admin_print_footer_scripts-hook_suffix/.

 > - Using the Scripts API allows other plugins to dequeue an `async`
 script.

 Yea, this is a good argument for supporting `async` scripts in Script
 Loader. Also (as I mentioned earlier) scripts with async can depend on
 "blocking" scripts without causing any problems.

 > Async scripts are already being used with before/after inline scripts.

 Thanks for the examples. May be missing something but don't actually see
 any `async` scripts with "after" scripts there.

 However imho a bigger concern is the proposed JS that handles "scripts
 after". Cloning a node and injecting it in the DOM as `text/javascript` is
 pretty much as bad as running that node's content with `eval()`. Here's
 what [https://developer.mozilla.org/en-
 US/docs/Web/JavaScript/Reference/Global_Objects/eval#never_use_eval! MDN
 has to say about it]:

  Warning: Executing JavaScript from a string is an enormous security risk.
 It is far too easy for a bad actor to run arbitrary code when you use
 eval(). See Never use eval()!, below.

 Frankly I don't think that's acceptable. Are there any examples of big,
 popular sites like Google, Apple, FB, etc. that currently do something
 like this?

 > Based on all of this, I propose the following next steps:
 > 1. We agree to support `async` scripts in the script loader with
 dependencies (this is already implemented, but we can address specifics in
 the PR).
 > 2. We iron out remaining issues for how inline scripts are handled for
 defer and `async` scripts.

 Sure, number 1 sounds okay, even if plugins and themes don't get onboard.
 Not so sure about number 2 though. In my opinion there should be no
 support for "after" scripts for scripts with `async` and `defer`. If
 plugins really want to run something after a script is evaluated, that can
 be handled from the JS much better.

 Also there is one big unanswered question here: **Does adding support for
 `async` and `defer` would make it harder or impossible to add support for
 `module` scripts in WordPress?** I'd consider this questing a blocker.
 (Think there was a comment somewhere here talking about modules, can't
 find it now though.)

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