We're just assigning this in today's TAG call. One feedback point on the explainer: can you be more explicit about the user (not developer) need that is bring served here? https://w3ctag.github.io/design-principles/#priority-of-constituencies

To slightly restate that comment on the explainer: it starts from the need for developers to understand the history of the visibility of the page. But it doesn't say why developers want to understand that history and what benefits (to users, hopefuly) that understanding it could have. Knowing that is likely to be useful when evaluating whether the API meets that need.

I added two paragraphs in the first section to explain this.

@atanassov and I are looking at this in our "Cork" virtual face-to-face.

I think the underlying use case here seems pretty reasonable, but the concern discussed a good bit in w3c/performance-timeline#105 that visibility is not the same as throttling is a valid one. It seems that if pages want to use the throttling being done by the browser to judge the relevance of their performance metrics, they should probably have more direct information about that throttling. Browser heuristics for throttling could certainly change over time.

It's true, throttling also affects performance. But for paint metrics, I think that visibility is really necessary. Long term, I think we'd like an API that exposes some CPU / network throttling. Combined, I think that those three states provide a decent picture of the state of the page, which can then be used to judge the performance metrics accordingly. If reviewers here think that these three states (visibility, cpu throttling, network throttling) need to be in a single API then we could change the name and I'm open to suggestions :)

Sorry for not coming back to this for so long... my concern wasn't really about things like cpu or network throttling. Rather, it was about whether visibility state is exactly the condition that causes painting not to occur and thus mess up the metrics like "First Contentful Paint"... and even if it is exactly that condition today, whether it's guaranteed to continue to be that condition in the future. If it's not... would this use case be better addressed by something that exposes exactly the relevant condition? Or is this useful in other ways even if it's not that exact condition?

(on the other hand, maybe the errors are only false positives (that is, cases where you might think you need to ignore the first paint metrics but the metrics would really be ok) and not false negatives, which might not be as big of a problem)

We discussed this in our mini-plenary during our virtual face-to-face meeting and agreed to close. It seems like a reasonable use case, and while I hope you'll consider my comment above (and feel free to email me if I miss a reply that you want me to see), we don't think it requires keeping this issue open.

One suggestion in https://github.com/w3c/performance-timeline/issues/105#issuecomment-739076819 was to consider instead exposing whether the 'rendering pipeline' of the browser is active. This sounds similar to what you mention, and may be worth exploring. That said, I do think it is important to measure the user experience, so from that perspective paints only matter in the foreground and not updating the rendering while in the foreground is bad user experience.

There may be some cases where paints matter while not in the foreground. One example I can think of is for app-switching or window-switching previews on various OSes.

That's a good point, and we've had conversations about this kinds of states, and it's not yet clear how we'll consider even visibility in those cases. We may need to expand the set of visibility states... Also, there have been ideas to expose the throttling concept as a separate measure, to help understand performance data. And throttling can be render-throttling, CPU-throttling, network-throttling, ... others maybe.