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