show a screenshot and calculate what % of the in-viewport pixels could be rendered with just the html page.
approach:
@patrickhulce What's this idea in aid of?
ps, maybe you could consider swapping 'crazy' for ' absurd' in the title?
What's this idea in aid of?
Identifying what % of above the fold content is blocked on additional network round trips essentially. Similar to "Optimize CSS Delivery" and "Prioritize visible content" rules from PSI where just browser definition of render-blocking CSS/JS doesn't cut it
This seems very similar to #6231, @patrickhulce can we fold this idea into that?
Hm I don't think so @exterkamp.
Web bloat score is all about capturing how many unnecessary bytes you're sending via screenshot byte size comparison.
This is all about capturing how much necessary content is available without downloading additional resources, which the old PSI did. i.e. what is renderable only from the main document? It seems like no one has complained that we stopped surfacing this audit in PSI though, so I'm not sure how important it is...
Might be able to remove psi-parity and swap to audit-proposal?
Retitled into the audit this would support.
This could incentivize 1.5MB html documents. We may have to add other audits to balance out. "Keep transfer sizes of render-blocking low for quick transfer"
Most helpful comment
Hm I don't think so @exterkamp.
Web bloat score is all about capturing how many unnecessary bytes you're sending via screenshot byte size comparison.
This is all about capturing how much necessary content is available without downloading additional resources, which the old PSI did. i.e. what is renderable only from the main document? It seems like no one has complained that we stopped surfacing this audit in PSI though, so I'm not sure how important it is...