Re: Visibility and performance entries

Another +1 for solution 2 given the two choices.

At Pinterest, we exclude timings from our reports if page visibility was
affected, but we don't add the visibility change listener that early and
are probably including a lot of tainted data. It would be great if we could
check the history of visibility changes, but as others have pointed out the
real goal is to separate out timings in which perf metrics are misleading
or browser throttling occurred.

On Fri, Apr 17, 2020 at 1:05 PM Philip Walton <philipwalton@google.com>
wrote:

> I fully support #2 as a general API, but I'm not 100% sure it's the right
> general solution to this particular problem.
>
> #2 assumes the *only* factor in tainting the result of a performance entry
> is page visibility, but that may not always be true (it may not even be
> true today).
>
> Off the top of my head, another potential reason for entry tainting could
> be a page loaded with a browser's devtools open and some sort of throttling
> applied, or a page loaded with something like webdriver or puppeteer. Site
> owners may want a way to exclude such entries from their reports.
>
> All this to say, perhaps we want both (though I'd recommend we start with
> #1).
>
>
> On Fri, Apr 17, 2020 at 12:07 PM Marcus Armstrong <
> marmstrong@tripadvisor.com> wrote:
>
>>
>> On Apr 17, 2020, at 10:25 AM, Noam Rosenthal <noam@webkit.org> wrote:
>>
>>
>>
>> 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.
>>
>>
>> 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.
>>
>>

-- 
Michelle Vu
Software Engineer | Core Product Performance