Changeset 60999 for trunk/src/wp-includes/script-modules.php

Timestamp:

10/21/2025 12:43:51 AM (3 months ago)

Author:

westonruter

Message:

Script Loader: Add support for printing script modules at wp_footer.

This brings API parity with WP_Scripts by implementing opt-in support for printing in the footer via an in_footer argument. This argument can be supplied via the $args array passed to wp_enqueue_script_module() or wp_register_script_module(), alongside the existing fetchpriority key introduced in #61734. It can also be set for previously-registered script modules via WP_Script_Modules::set_in_footer(). This is not applicable to classic themes since modules are enqueued while blocks are rendered after wp_head has completed, so all script modules are printed in the footer anyway; the importmap script must be printed after all script modules have been enqueued.

Script modules used for interactive blocks (with the Interactivity API) are automatically printed in the footer. Such script modules should be deprioritized because they are not in the critical rendering path due to interactive blocks using server-side rendering. Script modules remain printed at wp_head by default, although this default should be revisited since they have deferred execution (and they are printed in the footer for classic themes already, as previously noted). Moving a script module to the footer ensures that its loading does not contend with the loading of critical resources, such as the LCP element's image resource, and LCP is improved as a result.

This also improves specificity of some PHP types, it ensures that script modules can't be registered with an empty ID, and it prevents printing script modules with empty src URLs.

Developed in ​https://github.com/WordPress/wordpress-develop/pull/9867

Follow-up to [60704].

Props b1ink0, westonruter, jonsurrell, peterwilsoncc, vipulpatil, mindctrl.
See #61734.
Fixes #63486.

File:

• trunk/src/wp-includes/script-modules.php (modified) (4 diffs)

trunk/src/wp-includes/script-modules.php

@@ -65 +65 @@
  *     Optional. An array of additional args. Default empty array.
  *
+ *     @type bool                $in_footer     Whether to print the script module in the footer. Only relevant to block themes. Default 'false'. Optional.
  *     @type 'auto'|'low'|'high' $fetchpriority Fetch priority. Default 'auto'. Optional.
  * }
@@ -108 +109 @@
  *     Optional. An array of additional args. Default empty array.
  *
+ *     @type bool                $in_footer     Whether to print the script module in the footer. Only relevant to block themes. Default 'false'. Optional.
  *     @type 'auto'|'low'|'high' $fetchpriority Fetch priority. Default 'auto'. Optional.
  * }
@@ -184 +186 @@
         /*
          * The Interactivity API is designed with server-side rendering as its primary goal, so all of its script modules
-         * should be loaded with low fetchpriority since they should not be needed in the critical rendering path.
-         * Also, the @wordpress/a11y script module is intended to be used as a dynamic import dependency, in which case
-         * the fetchpriority is irrelevant. See <https://make.wordpress.org/core/2024/10/14/updates-to-script-modules-in-6-7/>.
+         * should be loaded with low fetchpriority and printed in the footer since they should not be needed in the
+         * critical rendering path. Also, the @wordpress/a11y script module is intended to be used as a dynamic import
+         * dependency, in which case the fetchpriority is irrelevant. See <https://make.wordpress.org/core/2024/10/14/updates-to-script-modules-in-6-7/>.
          * However, in case it is added as a static import dependency, the fetchpriority is explicitly set to be 'low'
          * since the module should not be involved in the critical rendering path, and if it is, its fetchpriority will
@@ -198 +200 @@
         ) {
             $args['fetchpriority'] = 'low';
+            $args['in_footer']     = true;
         }