You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The audit should fail in this scenario, it only becomes informative when the byte weight is below the passing threshold. However, reading the article it seems like this "informative on pass" system is causing some confusion so I'm open to changing it and going back to "green+hidden on pass".
Why not make it red when above the upper limit?
The audit will appear orange but never red because it is mostly an information dump. There aren't any specific improvements that we can recommend that will necessarily improve CWV.
In the case of this audit and several others, the pattern to make an audit informative when it's passing is unnecessary and causes more confusion than it's worth. I think there are still some audits that benefit from this pattern (e.g. LCP element audit) but we this is a case where it's not worth it. So I will go through all of our perf audits that use this pattern and try and reduce our usage of this pattern.
This recently published article from DebugBear raises some questions.
Is it possible to to "fail" this audit? Even when larger than the 4000 kilobytes
median
threshold of is this not relevant since it's anAudit.SCORING_MODES.INFORMATIVE
?If not, we should update the docs:
This appears to be above the 2667 KiB p10 threshold not 5,000 KiB.
Why not make it red when above the upper limit?
What does "roughly equivalent to 'resources'" mean?
The text was updated successfully, but these errors were encountered: