Further evaluate default thresholds for enqueued assets

[felixarntz]

#25 introduced a Site Health module that warns if the enqueued CSS or JS files are too many or if they are too large. But what is "too many" or "too large"? The original thread where the current (preliminary) thresholds were defined (mostly to have something to start with) begins in #25 (comment). We can now use this issue to discuss and evaluate further and once we have come to a conclusion, either adjust the thresholds or just close this issue.

To summarize, the thresholds (i.e. anything above will trigger a warning) of the current implementation are:

• 10 CSS assets
• 100KB of overall CSS enqueued
• 30 JS assets
• 300KB of overall JS enqueued

These values were initially decided on based on the metrics from https://almanac.httparchive.org/en/2021/javascript#how-much-javascript-do-we-load and https://almanac.httparchive.org/en/2021/css#usage (see #25 (comment) for more context). Let's see whether they actually hold up with further evaluation or where it might make sense to adjust them.

Aside: Note that all of these values can easily be changed (e.g. for testing) via filters perflab_aea_enqueued_scripts_threshold, perflab_aea_enqueued_scripts_byte_size_threshold, perflab_aea_enqueued_styles_threshold, and perflab_aea_enqueued_styles_byte_size_threshold.

cc @audrasjb @manuelRod

[felixarntz]

I'd like to call out the post https://infrequently.org/2021/03/the-performance-inequality-gap/ here as a useful resource to potentially base our thresholds on. It states:

We can now afford ~100KiB of HTML/CSS/fonts and ~300-350KiB of JS (gzipped).

While this post is now almost a year old, it also states right after that "this rule-of-thumb limit should hold for at least a year or two". I'm also not saying in any way that this post is the authority we should listen to, there is no right and wrong here. But I see the above statement as at least a confirmation that our current (JS and CSS size) thresholds based on the Web Almanac posts linked in the issue description are not too far off.

Maybe, given that this post allocates ~100KB for HTML, CSS and fonts, it might make sense to set the CSS threshold a bit lower than that, e.g. at 75KB?

[manuelRod]

@felixarntz though theoretically, it could make more sense to set a 75kb threshold, I don't think is realistic, how many wp installations have you seen which such a little size (sadly the norm is a heavy theme + heavy plugin usage)?
I'm afraid the warning will be triggered in a big % of WordPress websites and possibly it will lose value since it will be ignored.

[dainemawer]

Just reposting this here:

Just a quick insight on the thresholds. Not all sites are equal and to be honest, considering the versatility of WP environments, page builders etc - those thresholds are going to get gobbled up incredibly quickly. Starting a fresh theme is not equal to starting with 0kb of JS or CSS - wp-includes enqueues a ton of stuff by default.

It's a bit unfair on the user to assume that they would easily be able to control a threshold of a 100kb of CSS or 10 CSS assets when WP is already enqueuing 3 or 4 assets by default. Just installing Gravity Forms and rendering a form would enqueue a number of assets with poor code coverage and then your thresholds would be met.

What do we do in the case where we have a large site, maybe a high-traffic news site for instance? Those thresholds would more than likely be unrealistic. This is where Performance Budgets come into play - and in my opinion is probably an area that is beyond the scope of WP. I know Im playing a bit of devils advocate here but providing context is important. You would be hard-pressed to find major sites, or even minor sites running on WP with such low metrics. Im not advocating by any means for larger metrics here, but we do need to be realistic about the fact that we have no control over plugins or users.

Part of me leans to allowing users to add in their own thresholds, though that would more than likely make things redundant. Technically, you could include 100 scripts of 1KB and still be fine in terms of our thresholds above. In fact, that would still be more performant than 10 scripts of 10kb. Just some insight!