A coworker pointed me to this thread on public-web-perf where exactly this proposal has been made before:
https://lists.w3.org/Archives/Public/public-web-perf/2014Jan/0047.html <https://lists.w3.org/Archives/Public/public-web-perf/2014Jan/0047.html> Reading through the posts there has given me an idea of the challenges here, which is what I was hoping for when I sent the original email. It looks like we will need to gather some data about web compatibility before going forward, especially since other specs like the Vibration API reference the Page Visibility spec. I do want to clarify one other thing: we’re definitely not yet at the point of implementing this in Gecko, especially not in a release version. We think this functionality is important, and modifying the Page Visibility spec is one way to make it accessible to the web. It’s probably even the nicest way to make it accessible to the web, if it’s feasible. But it’s not certain that it’s web compatible or that everyone agrees this is the best way to go; we’re at the starting point of the process here. I’d be interested to hear any comments that others may have! Thanks, - Seth > On Mar 30, 2015, at 3:47 PM, Seth Fowler <s...@mozilla.com> wrote: > > I think we should modify the Page Visibility spec to let UA’s take actual > visibility of iframes into account when deciding if an iframe is hidden. > > Right now, the visibility of an iframe is the same as that of the top level > browsing context it’s embedded in. Here are the details: > > http://www.w3.org/TR/page-visibility/ > <http://www.w3.org/TR/page-visibility/> > > This design doesn’t do much for iframes which may be doing significant work, > though. The most obvious example is HTML5 ads. These ads may be performing > significant work - computation, network IO, rendering, etc. Some or all of > that work is often unnecessary when the ad is outside the viewport. Having an > API that would allow those ads to throttle back their work when they’re not > visible could have significant positive effects on performance and battery > life. > > We could get these benefits through a very simple modification of the Page > Visibility spec. We should make the visibility of iframes independent of the > top-level browsing context, and instead let UA’s take the actual visibility > of the iframes into account. If an iframe has been scrolled out of the > viewport, has become occluded, or has otherwise been rendered non-visible, we > should regard the iframe as hidden and dispatch a visibilitychange event to > let the iframe throttle itself. > > I think it’s worth noting that requestAnimationFrame could cover some of the > rendering-related part of this issue, but it’s frequently the case that > iframes are performing a good deal of computation and IO that isn’t tied to > requestAnimationFrame. Even for the rendering case, the requestAnimationFrame > API doesn’t give iframes any way to detect this kind of transition between a > state where fast rendering is important and a state where it’s not useful, so > in practice extending the Page Visibility spec in this way will often be > useful even for iframes which rely mostly on requestAnimationFrame. I think > we should view this change as complementary to the benefits that > requestAnimationFrame can give us. > > If there’s willingness to change the spec, this is a change we’d be > interested in making in Gecko in the near term. > > Sound good? > > Thanks, > - Seth
