@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?

Create Site Health Audit Enqueued Assets module #25

Description

Activity

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions