#64076: Emoji loader script can be moved to the footer since non-critical #10145

westonruter · 2025-10-04T03:44:56Z

Trac ticket: https://core.trac.wordpress.org/ticket/64076

This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.

github-actions · 2025-10-04T03:45:07Z

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props westonruter, wildworks.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

github-actions · 2025-10-04T04:08:08Z

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

The Plugin and Theme Directories cannot be accessed within Playground.
All changes will be lost when closing a tab with a Playground instance.
All changes will be lost when refreshing the page.
A fresh instance is created each time the link below is clicked.
Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

…_wpemojiSettings

westonruter · 2025-10-04T04:12:51Z

src/js/_enqueues/lib/emoji-loader.js

-		// Sets DOMReady to false and assigns a ready function to settings.
-		settings.DOMReady = false;
-		settings.readyCallback = () => {
-			settings.DOMReady = true;
-		};


This code appears to be a vestige of when the emoji was first introduced in 4.2:

wordpress-develop/src/wp-includes/js/wp-emoji-loader.js

Lines 65 to 85 in 7e57307

settings.DOMReady = false;

settings.readyCallback = function() {

settings.DOMReady = true;

};

if ( ! settings.supports.simple || ! settings.supports.flag ) {

ready = function() {

settings.readyCallback();

};

if ( document.addEventListener ) {

document.addEventListener( 'DOMContentLoaded', ready, false );

window.addEventListener( 'load', ready, false );

} else {

window.attachEvent( 'onload', ready );

document.attachEvent( 'onreadystatechange', function() {

if ( 'complete' === document.readyState ) {

settings.readyCallback();

}

} );

}

The logic was greatly simplified since then, now that DOMContentLoaded is supported by all supported browsers. Also, now that this script is loaded as a module, the DOM will have already been loaded anyway. So it seems like this logic and the corresponding logic in src/js/_enqueues/wp/emoji.js is now unnecessary.

westonruter · 2025-10-04T04:14:58Z

src/js/_enqueues/wp/emoji.js

-		/**
-		 * Initialize our emoji support, and set up listeners.
-		 */
-		if ( settings ) {


Since this script is loaded by the wp-emoji-loader.js, we know that window._wpemojiSettings will always be defined. Otherwise, if it is not, then the load function would never be executed. So this whole block of code doesn't make sense to me.

src/js/_enqueues/lib/emoji-loader.js

…into trac-64076-move-emoji-loader-to-footer

westonruter · 2025-10-06T00:08:41Z

src/js/_enqueues/wp/emoji.js

-		 * Initialize our emoji support, and set up listeners.
-		 */
-		if ( settings ) {
-			if ( settings.DOMReady ) {


And since wp-emoji-loader.js now runs as a script module, it is deferred to execute at the point that the DOM is constructed, so we know it is ready to go.

t-hamano

Thanks for the PR! Everything seems to be working fine.

This is not a blocker, just a question.

Are we allowed to use the const format in core JS exposed to the front-end? My code editor gives me the error Parsing error: The keyword 'const' is reserved.
What if the consumer is loading some script in the head tag and is referencing window._wpemojiSettings there?

westonruter · 2025-10-06T04:14:55Z

Are we allowed to use the const format in core JS exposed to the front-end? My code editor gives me the error Parsing error: The keyword 'const' is reserved.

Yes, because core blocks use const. I see the same from my IDE, and I think it's just because we don't have an ESLint config yet in the project. See Core-31823.

What if the consumer is loading some script in the head tag and is referencing window._wpemojiSettings there?

As part of Core-63842, we did a search for any plugins using this global: #9531 (comment)

There just seems to be one relevant: WooPayments. And yet, it doesn't seem to be impacted in my testing, and I concluded with this: #9531 (comment).

westonruter · 2025-10-06T04:21:22Z

I added this .eslintrc.js to the root of the repo:

module.exports = {
	extends: [ 'plugin:@wordpress/eslint-plugin/recommended' ],
};

That makes that error with const go away, but then it starts catching a bunch of other things that haven't yet been enforced before for core, like:

ESLint: Invalid JSDoc @type type "object"; prefer: "Object". (jsdoc/check-types)

westonruter · 2025-10-06T04:24:07Z

Ah, I've just added /* eslint-env es6 */ comment which makes that error go away.

t-hamano · 2025-10-06T04:25:29Z

We can probably ignore the warnings in the code editor for now.

westonruter · 2025-10-06T04:25:59Z

I'll go ahead and commit this now to fix that E2E test in Gutenberg, and we can continue iterating if there is any additional code review feedback.

…`wp_print_footer_scripts`. This removes ~3KB of HTML from the critical rendering path of markup in the `head`, thus marginally improving FCP/LCP in slower connections. It also fixes a Firefox issue with script modules by ensuring the emoji loader script module is printed after the `importmap`. Existing plugins that disable emoji by unhooking the action as follows will continue to work as expected: remove_action( 'wp_head', 'print_emoji_detection_script', 7 ); Additionally, some obsolete `DOMReady` and `readyCallback` logic was removed. A script module (as it has a deferred execution) only ever executes when the DOM is fully loaded. This means there was no need for a `DOMContentLoaded` event which was removed in [60899], and the remaining ready detection logic can be removed. Follow-up to [60899]. Developed in #10145. Props westonruter, wildworks. Fixes #63842. Fixes #64076. git-svn-id: https://develop.svn.wordpress.org/trunk@60902 602fd350-edb4-49c9-b593-d223f7449a82

github-actions · 2025-10-06T04:50:19Z

A commit was made that fixes the Trac ticket referenced in the description of this pull request.

SVN changeset: 60902
GitHub commit: 3cba156

This PR will be closed, but please confirm the accuracy of this and reopen if there is more work to be done.

github-actions · 2025-10-06T04:50:20Z

A commit was made that fixes the Trac ticket referenced in the description of this pull request.

SVN changeset: 60902
GitHub commit: 3cba156

This PR will be closed, but please confirm the accuracy of this and reopen if there is more work to be done.

…`wp_print_footer_scripts`. This removes ~3KB of HTML from the critical rendering path of markup in the `head`, thus marginally improving FCP/LCP in slower connections. It also fixes a Firefox issue with script modules by ensuring the emoji loader script module is printed after the `importmap`. Existing plugins that disable emoji by unhooking the action as follows will continue to work as expected: remove_action( 'wp_head', 'print_emoji_detection_script', 7 ); Additionally, some obsolete `DOMReady` and `readyCallback` logic was removed. A script module (as it has a deferred execution) only ever executes when the DOM is fully loaded. This means there was no need for a `DOMContentLoaded` event which was removed in [60899], and the remaining ready detection logic can be removed. Follow-up to [60899]. Developed in WordPress/wordpress-develop#10145. Props westonruter, wildworks. Fixes #63842. Fixes #64076. Built from https://develop.svn.wordpress.org/trunk@60902 git-svn-id: http://core.svn.wordpress.org/trunk@60238 1a063a9b-81f0-0310-95a4-ce76da25c4cd

…`wp_print_footer_scripts`. This removes ~3KB of HTML from the critical rendering path of markup in the `head`, thus marginally improving FCP/LCP in slower connections. It also fixes a Firefox issue with script modules by ensuring the emoji loader script module is printed after the `importmap`. Existing plugins that disable emoji by unhooking the action as follows will continue to work as expected: remove_action( 'wp_head', 'print_emoji_detection_script', 7 ); Additionally, some obsolete `DOMReady` and `readyCallback` logic was removed. A script module (as it has a deferred execution) only ever executes when the DOM is fully loaded. This means there was no need for a `DOMContentLoaded` event which was removed in [60899], and the remaining ready detection logic can be removed. Follow-up to [60899]. Developed in WordPress/wordpress-develop#10145. Props westonruter, wildworks. Fixes #63842. Fixes #64076. Built from https://develop.svn.wordpress.org/trunk@60902 git-svn-id: https://core.svn.wordpress.org/trunk@60238 1a063a9b-81f0-0310-95a4-ce76da25c4cd

westonruter added 2 commits October 3, 2025 20:42

Print emoji loader at wp_print_footer_scripts instead of wp_head

4a334e8

Remove unnecessary then

5afbdcb

westonruter mentioned this pull request Oct 4, 2025

Use script module for emoji-loader with settings exported via JSON #9531

Closed

Remove apparently unnecessary DOMReady and readyCallback

d8845a0

Update comment to note importance of wp-emoji.js reading from window.…

ca22ac9

…_wpemojiSettings

westonruter commented Oct 4, 2025

View reviewed changes

westonruter requested review from peterwilsoncc and sirreal October 4, 2025 04:15

westonruter commented Oct 4, 2025

View reviewed changes

src/js/_enqueues/lib/emoji-loader.js Outdated Show resolved Hide resolved

westonruter requested review from swissspidy and t-hamano October 5, 2025 20:49

westonruter added 2 commits October 5, 2025 17:04

Merge branch 'trunk' of https://github.com/WordPress/wordpress-develop …

407148e

…into trac-64076-move-emoji-loader-to-footer

Clarify where wp-emoji.js is

5f83576

westonruter commented Oct 6, 2025

View reviewed changes

t-hamano approved these changes Oct 6, 2025

View reviewed changes

Add eslint-env es6 comment

4104301

github-actions bot closed this Oct 6, 2025

	settings.DOMReady = false;
	settings.readyCallback = function() {
	settings.DOMReady = true;
	};

	if ( ! settings.supports.simple \|\| ! settings.supports.flag ) {
	ready = function() {
	settings.readyCallback();
	};

	if ( document.addEventListener ) {
	document.addEventListener( 'DOMContentLoaded', ready, false );
	window.addEventListener( 'load', ready, false );
	} else {
	window.attachEvent( 'onload', ready );
	document.attachEvent( 'onreadystatechange', function() {
	if ( 'complete' === document.readyState ) {
	settings.readyCallback();
	}
	} );
	}

#64076: Emoji loader script can be moved to the footer since non-critical #10145

#64076: Emoji loader script can be moved to the footer since non-critical #10145

Conversation

westonruter commented Oct 4, 2025

Uh oh!

github-actions bot commented Oct 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions bot commented Oct 4, 2025

Test using WordPress Playground

Some things to be aware of

Uh oh!

westonruter Oct 4, 2025

Choose a reason for hiding this comment

Uh oh!

westonruter Oct 4, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

westonruter Oct 6, 2025

Choose a reason for hiding this comment

Uh oh!

t-hamano left a comment

Choose a reason for hiding this comment

Uh oh!

westonruter commented Oct 6, 2025

Uh oh!

westonruter commented Oct 6, 2025

Uh oh!

westonruter commented Oct 6, 2025

Uh oh!

t-hamano commented Oct 6, 2025

Uh oh!

westonruter commented Oct 6, 2025

Uh oh!

github-actions bot commented Oct 6, 2025

Uh oh!

github-actions bot commented Oct 6, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

github-actions bot commented Oct 4, 2025 •

edited

Loading