6195

Unfortunately, this workaround introduced a performance regression for every page where wp-i18n is enqueued.

wp-i18n isn't too large a script, but it does depend on the considerably larger wp-polyfill, which as a result also gets enqueued in <head>. From a performance point of view, it would be a nice win if we managed to fix this in a different way, since scripts in the <head> are render-blocking and can thus have an impact on first paint and all subsequent paint metrics.

Step-by-step reproduction instructions

Enqueue wp-i18n
Verify that it gets enqueued in <head> even if you specified in_footer to be true

Screenshots, screen recording, code snippet

No response

Environment info

No response

Please confirm that you have searched existing issues in the repo.

[X] Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

[X] Yes

sgomes commented 1 week ago

CC @jsnajdr, who wrote an extensive analysis of the issue previously.

Hey @jsnajdr! 👋 It's been a while since this workaround was put in place. Are you aware of a better approach we could use now, to avoid having to place this script in the <head>?

jsnajdr commented 1 week ago

If it's only (or mainly) about wp-i18n, some good solutions could be:

get rid of the wp-polyfill dependency. I doubt that wp-i18n really uses any polyfilled stuff. It's a very basic JavaScript.
make the polyfill smaller, or eliminate it. There could be server-side PHP code at the very beginning doing something like
```
if ( $user_agent === $latest_chrome ) {
wp_reregister_script( 'wp-polyfill', 'noop.js' );
}
```
Here I assume that a latest evergreen browser doesn't need any polyfilling at all, or very little.

sgomes commented 1 week ago

Thank you, @jsnajdr! Those are some good options I hadn't considered 👍

swissspidy commented 2 hours ago

To confirm, this is only an issue in Gutenberg because of the way GB overrides scripts?

From what I can see, wp-i18n and wp-polyfill in core are both registered to be in the footer, so maybe nowadays GB could try that as well?

Of course removing unnecessary dependencies is always a great option.

WordPress / gutenberg

`wp-i18n` always loads in the `<head>` #64614