Create Site Health Audit Enqueued Assets module

[ThierryA]

Similar to #4 and #5, would be great to include to work started by @audrasjb here as module 😄

[manuelRod]

Shouldn't we define messaging? Maybe tailor it for end-users?
Also, where this info is gonna show in the Site Health Screen?
Maybe all modules should be added under a custom tab?

[ThierryA]

Shouldn't we define messaging? Maybe tailor it for end-users?

+1 to that

Also, where this info is gonna show in the Site Health Screen?

Stacked with all other items and with a "Performance" badge, although that is not set in stone I guess.

Meta note, raising awareness of too much CSS/JS etc is a good start, doing so and providing the source of the "offenders" is one step more helpful, doing so AND providing an action to solve the issue is the pinnacle. The later is extremely hard without risking to break something indeed.

cc @westonruter who has a lot of experience with sourcing offenders 😉

[westonruter]

Yeah, identifying the theme/plugin responsible for enqueuing a script or stylesheet is something the AMP plugin does heavily. It also goes to the extent of sourcing where inline scripts/styles are coming from (e.g. via wp_localize_script(), wp_add_inline_script(), and wp_set_script_translations(), and wp_add_inline_style()). Beyond WP_Scripts and WP_Styles, it also goes to the extent of identifying the source of scripts/styles that are printed manually, such as in wp_head or wp_footer. Not all of this will be applicable or important perhaps in the beginning, but I think it's all doable for core.

[manuelRod]

guys, I can work bringing https://github.com/audrasjb/site-health-audit-enqueued-assets/blob/master/site-health-audit-enqueued-assets.php to a module, and then we can discuss further messaging/features?

[ThierryA]

@manuelRod thanks for raising your hand. Sure you can either open a PR bringing the code in a module and we discuss further on it (I have some thoughts about the > 10 asset as a signal) or alternatively edit this issue description with more details about the approach and we continue discussing in this issue. Either war works 😄

[manuelRod]

@ThierryA here is the PR: #54

We can continue the conversation here.

So we are moving from 10 assets to total filesize, but should we maybe keep a combination of both? I think it is still useful to know the number of resources enqueued since we can still recommend concatenating them.

[westonruter]

If concatenation is recommended that would then probably also require recommending an optimization plugin that does such such concatenation. Otherwise, concatenation would only be something that could be done in the context of a theme/plugin's individual scripts. In this latter case, the call to action would be for the site owner to consider an alternative theme/plugin.

[ThierryA]

Continuing the comment thread conversation here. I would suggest to have a discussion with the broader group about the scripts and stylesheets size threshold as well as the number of instance if we decide to include this as a signal too.

https://almanac.httparchive.org/en/2021/javascript#how-much-javascript-do-we-load and https://almanac.httparchive.org/en/2021/css may help us understanding the current state of the web

We could base the threshold on CWV guidance if that resonate with everyone.

@felixarntz @adamsilverstein paging you here as well, would love more folks thoughts on this too.

[adamsilverstein]

Also relevant: the CMS section of the web almanac also breaks out some WordPress specific stats showing the high number of resources enqueued: https://almanac.httparchive.org/en/2021/cms#plugins

[felixarntz]

@manuelRod @ThierryA @adamsilverstein Looking at the two posts on JS and CSS usage above, one thing to realize is that (at least on desktop) the amount of JS and the overall file size of JS at the 75th percentile is about 3 times as much as the respective value for CSS.

I'm focusing on specifically the 75th percentile since that is where for CSS we are above 10 assets, which is where based on the PR right now we would warn the user. At the same (75th) percentile, the CSS file size is slightly above 100KB, so that may be a good relative value to use. For JS then, the 75th percentile has above 30 assets, and, at least on desktop, above 300KB. The value on mobile is a lot higher, but we should probably use the lower value as indicator for boundary.

There's somewhat two things we need to resolve here: We need to first figure out a relative relationship between the 4 metrics in how the thresholds should relate to each other, and then we need to determine what is the appropriate threshold to warn users. If we agree that warning users when they have more than 10 CSS assets enqueued is a good approach, a good approach might be the following for the 4 thresholds:

• Warn sites that have >10 CSS assets enqueued.
• Warn sites that have >100KB of CSS enqueued.
• Warn sites that have >30 JS assets enqueued.
• Warn sites that have >300KB of JS enqueued.

That's an initial idea, of course subject to discussion. While some of these numbers may seem high, we also don't want to make it "almost pointless" in that almost every site would then get warned. We can always lower the thresholds to become stricter later. Thoughts?