Re: Visibility and performance entries

Similar to previous votes, +1 for #2.

I've been running into issues with this exact problem recently (paint
timing entries being difficult to reason about when the page is
backgrounded, metric values occasionally being inflated due to how Chromium
handles background tabs) and would love a better solution here for
developers.

An observer with a buffered flag being added to Page Visibility would
address my team's needs well.

On Fri, Apr 17, 2020 at 8:51 AM Riviello, John <John_Riviello@comcast.com>
wrote:

> Hi everyone,
>
>
>
> I’m not a WG member but I figured I’d at least weigh-in with my experience
> here as a web developer if that’d be helpful to the group. I’ve been taking
> the approach of #2 manually for a few years (you can see exactly how in
> https://github.com/Comcast/Surf-N-Perf#including-the-code-in-your-project
> if you’re curious). When looking at the overall performance of my web
> applications, I typically just throw out the instances when the page was
> backgrounded when computing performance metrics (which would make #1
> sufficient). However, having the detailed history is useful when looking
> back on an individual anonymous session for performance anomalies.
>
>
>
> So that’s essentially a vote for #2, as I could remove that bit of code
> from my web apps to set up those observers.
>
>
>
> More important to me though is that there is a way to effectively feature
> detect whichever solution you end up implementing, so that I could continue
> with my approach for older browser versions and do not have to set up those
> observers for browsers that support the new feature.
>
>
>
> Thanks for your work on this!
>
>
>
> -John Riviello
>
>
>
>
>
> *From: *Nicolás Peña <npm@google.com>
> *Date: *Friday, April 17, 2020 at 10:15 AM
> *To: *public-web-perf <public-web-perf@w3.org>
> *Subject: *Visibility and performance entries
> *Resent-From: *<public-web-perf@w3.org>
> *Resent-Date: *Friday, April 17, 2020 at 10:13 AM
>
>
>
> Hey all,
>
>
>
> At our last call, we discussed the problem
> <https://urldefense.com/v3/__https:/github.com/w3c/paint-timing/issues/40__;!!CQl3mcHX2A!R4fODtYKQCw8UM6e_AzNtk_lSUQFs317oMNpEgtB-wHdRuueM4f0GWth0hWv4I-kVfr1$>
> 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.
>
>
>
> 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://urldefense.com/v3/__https:/w3c.github.io/page-visibility__;!!CQl3mcHX2A!R4fODtYKQCw8UM6e_AzNtk_lSUQFs317oMNpEgtB-wHdRuueM4f0GWth0hWv4DeilNpz$> 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?
>