[wp-trac] [WordPress Trac] #12009: Add support for HTML 5 "async" and "defer" attributes
WordPress Trac
noreply at wordpress.org
Mon May 22 00:52:16 UTC 2023
#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
More information about the wp-trac
mailing list