Re: Visibility and performance entries

On Fri, 17 Apr 2020 at 17:14 Nicolás Peña <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.