Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Questions regarding "Avoid enormous network payloads" audit #16265

Open
tunetheweb opened this issue Nov 29, 2024 · 2 comments · May be fixed by #16315
Open

Questions regarding "Avoid enormous network payloads" audit #16265

tunetheweb opened this issue Nov 29, 2024 · 2 comments · May be fixed by #16315
Assignees
Labels

Comments

@tunetheweb
Copy link
Member

This recently published article from DebugBear raises some questions.

To help surface the highest payloads, Lighthouse flags pages whose total network requests exceed 5,000 KiB.

This appears to be above the 2667 KiB p10 threshold not 5,000 KiB.

@adamraine
Copy link
Member

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 an Audit.SCORING_MODES.INFORMATIVE?

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.

What does "roughly equivalent to 'resources'" mean?

This is a comment for translators. It is meant to give extra context to the word "Payload".

@adamraine
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants