Re: Visibility and performance entries

On Apr 17, 2020, at 10:25 AM, Noam Rosenthal <noam@webkit.org<mailto:noam@webkit.org>> wrote:



On Fri, 17 Apr 2020 at 17:14 Nicolás Peña <npm@google.com<mailto:npm@google.com>> wrote:
Hey all,

At our last call, we discussed the problem<https://github.com/w3c/paint-timing/issues/40> of paint timing entries being hard to reason about when the page has been backgrounded. We noted that this does not only affect paint timing and hence requires a more holistic solution so developers can easily choose to discard certain performance entries whenever the page has been backgrounded before the creation of the entry.
does this also take into account suspending /restoring documents to session history before e.h.paint timing was reported? Maybe it should...

There are two different potential solutions for this, and we're looking for feedback about which one is preferable:

1. Provide a boolean in PerformanceEntry that specifies whether the Window has even been hidden between the Window creation time and the time of creation of the PerformanceEntry.
2. Add a PageVisibilityObserver with 'buffered' flag to the Page Visibility API<https://w3c.github.io/page-visibility> so that developers can get a full history of the visibility changes of the Document. Right now, onvisibilitychange can we used to obtain any visibility changes in the future, but none from the past.

(1) has the advantage of being very explicit and easier to use for the use-case of discarding entries, but (2) has the advantage of being more flexible and enabling more use-cases from the ability to reconstruct the full visibility history of the page. What do you think is more useful?
I prefer (2), it’s a bit more future proof and leaves decisions to the developer. Or have a PerformanceEntry type rather than its own observer type... that way the same observer can understand the whole timeline.

But I think either would work.

For our internal performance monitoring we’ve made a best effort at (2) by the addition of an early-in-page inline onvisibiltychange listener. While this information directly impacts paint timing, we also care about it for other metrics as a proxy for browser throttling behavior—I’d personally prefer more direct information about when throttling is undertaken as a general approach.