Re: Visibility and performance entries

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?