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 2 months 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 2 months 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 2 months ago

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

swissspidy commented 2 months 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.

sgomes commented 2 months ago

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

That is my understanding, yes.

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?

I don't think that anything has fundamentally changed that made the issue go away, as it wasn't directly related with wp-i18n being in the footer (I believe that was already the case), but some complex interactions between translations and concatenation. https://core.trac.wordpress.org/ticket/55628 should have the details.

WordPress / gutenberg

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

Description

39497 introduced a workaround for the bugs described in https://core.trac.wordpress.org/ticket/55628 and https://core.trac.wordpress.org/ticket/6195

Step-by-step reproduction instructions

Screenshots, screen recording, code snippet

Environment info

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

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