Marking the above issue as Untriaged as this is a new feature request.

Dev team will take a call on the above issue.

Thank you!

CC'ing some folks who might be interested in giving input on this request.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Adding some other people who might be interesting this. panicker, is this an area you're pursuing with paint timing?

Could you elaborate more on how would developers use this signal?
eg. as a replacement for DCL for fetching JS or ordering certain fetches etc. ?

Hi – yes, that's the idea: I sometimes audit web sites and see that the developers try to defer certain resources until it makes sense to load them, but they fail for lack of fitting events. I am thinking of an event after which any loading will not delay the fetching of resources needed for the rendering of the visible part of the page. By this, I mean what ends up being in view, not necessarily below-the-fold parts that influence the layout computation. But I guess any addition in this direction should improve the available means to prioritise what's actually visible, while images below the fold, tracking pixels etc. would be deferred.

This raises the question of whether or not developers should ever use PerformanceObserver data to influence page behavior.

I'm inclined to say that they probably shouldn't, which implies that an event would make more sense here, if we decide this is useful.

Would this be much more useful than requestIdleCallback()? Another option would be to ensure that rIC to handles this case appropriately.

FWIW, I think this discussion belongs on WICG and/or GitHub / public-web-perf@ list, such that we can get more eyeballs and input from other vendors.

uenke@ would you be willing to define a crisp use case and publish it on, say, WICG?

BTW this is not about using Performance Observer to decide page behavior -- we should not do that.
I'm interpreting this as exposing new (lifecycle oriented) signals for loading.
+1 for WICG thread.

That's what I thought, regarding PO.
We'd probably want to also expose this signal via PerformanceObserver though, right?

lifecycle events are generally orthogonal to performance measurement, although sites will use it in analytics anyway. we should make sure they are high quality signals.
(we probably don't need parallel signals in PO unless there's a good reason)

As you seem to agree that this rather belongs on discourse.wicg.io, I took a note to make the case there once I get the time and, preferably, have a customer case at hand that would demonstrate the need.

Thanks for your feedback!

Sounds like this request is moving to wicg, so closing this bug. Please reopen if I misunderstood.