Web page load performance

[adamwoodnz]

Description

We've started performance testing of the new wordpress.org home and download pages and we're getting low Page Speed scores due to a couple of Gutenberg related issues. This Chrome DevTools waterfall and coverage report shows them:

1. Scripts loaded in the head causing render blocking

The waterfall shows there are 9 Gutenberg scripts loaded in the head, including some large ones: react-dom, lodash, date, moment.

Is there a reason for the plugin to load so many scripts in the head or could they be moved to the end of the body like others?

2. Unused Javascript

The coverage report shows that of the 770k for the Gutenberg components script, 74.9% of it is unused.

Is any work in progress to lazy load components as required by the webpage?

Step-by-step reproduction instructions

Visit https://wordpress.org/main-test/ and https://pagespeed.web.dev/report?url=https%3A%2F%2Fwordpress.org%2Fmain-test%2F&form_factor=mobile

Observe Gutenberg scripts being loaded in the head and associated Page Speed diagnostics and opportunities.

Screenshots, screen recording, code snippet

No response

Environment info

WordPress 6.1-alpha-53840 running WordPress.org Main Block Theme, 2022 theme.

Gutenberg 13.8.0

Google Chrome on MacOS, Google Page Speed

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

Yes

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

N/A

[peterwilsoncc]

This looks to be caused by blocks.json enqueuing scripts in the header rather than the footer. The source is within register_block_script_handle() in WordPress Core.

The site in question is using the wp.org multisite-latest-posts block as best I can tell, thus bringing all the assets to the HTML header.

[mtias]

@adamwoodnz the block Peter refers to is the one pulling in all those dependencies, for visibly no reason that I can tell. Not sure how that block was designed, but it seems superfluos for it to be rendered client side instead of server side given it seems to have no interactivity affordances.

[ocean90]

Related core Trac ticket: Allow scripts registered via block.json to be enqueued in the footer

[TimothyBJacobs]

I think this is because the theme is using the Modal component from @wordpress/components to render a modal on the download page.

https://github.com/WordPress/wporg-main-2022/blob/4279809f9e39662a176cbdd0b46ad6863655a189/source/wp-content/themes/wporg-main-2022/src/components/download-modal/DownloadModal.js

You can see that in action when you click on the Download button.

The @wordpress/components package has a lot of dependencies, and I don't think it's really meant/ready to be used on the front-end.

[adamwoodnz]

Thanks for the feedback all, we'll discuss!

[adamwoodnz]

I see this ticket was closed #17079 and Modal was mentioned as being one of the components that could benefit from a separate package. We also faced this problem trying to use Spinner. Any appetite to reopen now?

Modal bundles all the functionality we need so we'd really like to continue using it. For now I'm going to see if we can improve the home page performance by only loading the download modal script on the download page. Hopefully the latest news plugin doesn't also cause the components import, although I suspect moment and date will still be loaded in the head.

[TimothyBJacobs]

Something you could potentially explore would be to limit the Webpack Dependency Extraction plugin to only handle @wordpress/i18n and instead let Webpack tree shake to generate a built file with only the needed JS included.

[Mamaduka]

I think the "Multisite Latest Posts" block's front.js can be refactored with vanilla JS and remove all React dependencies. It's currently loading ReactDOM, React, Moment, and a few other Block Editor components.

[tyxla]

A side note that Lodash has completely been removed - see #52571 and #17025.

[adamwoodnz]

Performance tests have improved since I posted this. Lodash removal is a definite win. We've now removed the modal code from the home page and only load it on /downloads. I'm yet to experiment with deferring scripts or tree shaking.

[mtias]

@adamwoodnz can this issue be closed? It seems that remaining work is more about optimizations on the wordpress.org website side.

[adamwoodnz]

@adamwoodnz can this issue be closed? It seems that remaining work is more about optimizations on the wordpress.org website side.

Yeah I think that's fair. I still think it would be great for the general usability and widespread adoption of @wordpress/components as a UI library, if components like Spinner, Modal, etc. could be imported separately without the full weight of the package, as suggested on #17079

[mtias]

They are not really designed for frontend use cases, though.