VisibilityStateEntry

[npm1]

Saluton TAG!

I'm requesting a TAG review of VisibilityStateEntry.

Exposes the initial visibility state of the page plus any visibility state changes that the page goes through to the PerformanceObserver, with buffered flag support.

• Explainer (minimally containing user needs and example code): url
• Security and Privacy self-review: I did not fill it out because the API does not really expose information that is not already available via the PageVisibility API. But if desired I can fill it out.
• GitHub repo (if you prefer feedback filed there): I will be adding this feature on this repo but feel free to comment on the doc or this issue for now.
• Primary contacts (and their relationship to the specification):
  • Nicolás Peña Moreno, @npm1, Google, will do the spec work.
  • Ilya Grigorik, @igrigorik, Google, WebPerf chair.
  • Nic Jansma, @nicjansma, Akamai, WebPerf chair.
  • Yoav Weiss, @yoavweiss, Google, WebPerf chair.
• Organization/project driving the design: Chromium
• External status/issue trackers for this feature (publicly visible, e.g. Chrome Status):
  Chrome implementation tracking bug
  Chrome status

Further details:

• I have reviewed the TAG's API Design Principles
• The group where the incubation/design work on this is being done (or is intended to be done in the future): W3C WebPerf WG
• The group where standardization of this work is intended to be done ("unknown" if not known): W3C WebPerf WG
• Existing major pieces of multi-stakeholder review or discussion of this design: see call minutes
• Major unresolved issues with or opposition to this design: N/A
• This work is being funded by: Google

We'd prefer the TAG provide feedback as (please delete all but the desired option):

💬 leave review feedback as a comment in this issue and @-notify @npm1

[torgo]

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

[dbaron]

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.

[npm1]

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

[dbaron]

@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.

[npm1]

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 :)

[dbaron]

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?

[dbaron]

(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)

[dbaron]

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.

[npm1]

One suggestion in w3c/performance-timeline#105 (comment) 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.

[dbaron]

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.

[npm1]

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.