Script loading strategies are now employed in core Core is the set of software required to run WordPress. The Core Development Team builds WordPress. and bundled themes to improve performance of loading scripts with defer and async attributes. Additionally, scripts on the frontend and login screen are now constructed using script helper functions, making it possible to utilize Content Security Policy to harden against any XSS vulnerabilities. This change also has back-compat implications for the obsolete use of the clean_url filter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. to inject defer and async attributes; plugins should now use the script loading strategies API An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. instead. The full details follow.
Utilizing script loading strategies
In WordPress 6.3, the script loading strategies were introduced (#12009), enabling scripts to finally have an API for marking them to be printed with async or defer without resorting to filtering script_loader_tag (or worse clean_url, per below). For more information, refer to the dev note on Registering scripts with async and defer attributes in WordPress 6.3.
In WordPress 6.4, script loading strategies are now being employed for frontend scripts in core and bundled themes. For the most part, the defer loading strategy is used since it is more consistent in its loading behavior, in that a defer script always executes once the DOM has loaded; a script with `async` may actually block Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. rendering if it is already cached.
Additionally, scripts now loading with defer have been moved from the footer to the head so that they are discovered earlier while the document is loading and can execute sooner once the document is loaded. The changes include:
- The
defer loading strategy is being used for all block view scripts, such as the Navigation, File, and Search blocks as well as any blocks added by plugins. (#59115)
- The
defer loading strategy is also now being used for the wp-embed script which is included when there is a WordPress post embed present on the page. (#58931)
- Frontend scripts used in bundled themes also use the
defer loading strategy. (#59316)
- The
async loading strategy is used for the comment-reply script, and it continues to load in the footer since it is low priority being that comments are not visible when first viewing a post. (#58870)
If there is any theme or plugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party that enqueues a script that depends on any of the above scripts (which is unlikely), the script loading strategy API considers the dependents of a delayed script so that if any of them are blocking, the delayed script will also fall back to blocking. This ensures the execution order is preserved.
Eliminating manual construction of script tags
Throughout WordPress core there have been many places where script tags are manually constructed instead of relying on the helper functions wp_print_inline_script_tag(), wp_get_inline_script_tag(), wp_print_script_tag(), and wp_get_script_tag(). In WordPress 6.4 via #58664, these functions are now employed for all scripts printed to the frontend and for scripts printed on the login screen. This includes all scripts printed via wp_enqueue_script() as well as other functions that interact with WP_Scripts, namely wp_add_inline_script() and wp_localize_script(). More details on #59446 which continues this work throughout wp-admin (and super admin).
Using these helper functions makes core easier to read and maintain with less code duplication. It also opens the door to being able to leverage Content Security Policy (CSP) for hardening WordPress against script injection attacks (XSS vulnerabilities). This is due to these functions allowing additional attributes to be added to script tags via the wp_script_attributes and wp_inline_script_attributes filters, allowing the nonce attribute to be added. Refer to an example plugin that enables Strict CSP on the frontend and login screens.
On a related note to the script loading strategies above, there is one aspect of this change that breaks a prior method for adding async or defer to scripts using the clean_url filter:
<?php
// ⚠ WARNING: Do not do this.
function defer_parsing_of_js ( $url ) {
if ( FALSE === strpos( $url, '.js' ) ) return $url;
if ( strpos( $url, 'jquery.js' ) ) return $url;
return "$url' defer ";
}
add_filter( 'clean_url', 'defer_parsing_of_js', 11, 1 );
This no longer works with WordPress 6.4 because the script URL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org is now escaped when constructing the HTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. attributes for the script tag A directory in Subversion. WordPress uses tags to store a single snapshot of a version (3.6, 3.6.1, etc.), the common convention of tags in version control systems. (Not to be confused with post tags.). So previously if it resulted in this script tag:
<script src='/wp-includes/js/underscore.js?ver=1.13.4' defer></script>
It now results in:
<script src="/wp-includes/js/underscore.js?ver=1.13.4%27%20defer"></script>
The clean_url filter (introduced in WP 2.3) never should have been used for this purpose once the script_loader_tag filter was introduced in WP 4.1. The clean_url filter runs on every single URL on the page, not just the script URLs. Also, the clean_url filter approach relied on scripts being printed with single-quoted HTML attribute values.
Plugins continuing to use the clean_url filter in this way will find that the desired attribute is no longer injected, and that the attribute instead appears appended to the ver query parameter for the script. Plugins seeking to add defer or async attributes should instead now use the script loading strategies API. More on the dev note Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include a description of the change, the decision that led to this change, and a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase. Registering scripts with async and defer attributes in WordPress 6.3.
Props to @webcommsat and @flixos90 for reviewing.
#6-4, #dev-notes, #dev-notes-6-4
