Re: WebPerfWG call - October 8 @ 10am PT / 1pm ET

Minutes
<https://docs.google.com/document/d/e/2PACX-1vQWJIKu86xeKuSFBr_S7BCxw9sgLmGa8BSBuD6iD8Gos32rwVfjMk3J5EP0cnUrwKl6yWLYW50vQ8vm/pub>
for
this call:
Participants

Nic Jansma, Yoav Weiss, Peter Perlepes, Noam Helfman, Steven Bougon,
Nicolás Peña Moreno, Michal Mocny, Carine Bournez, Alex Christensen, Annie
Sullivan, Benjamin de Kosnik
Next Call: November 5th @ 10am PST / 1pm ESTWebPerf WG TPAC meetings:
https://bit.ly/webperf-tpac20
<https://www.google.com/url?q=https://bit.ly/webperf-tpac20&sa=D&ust=1603044235645000&usg=AOvVaw2UrhhUI9Qab0mfanSYCuDx>
Minutes

   - TPAC discussion


   - Register


   - https://www.w3.org/2020/10/TPAC/registration.html
   <https://www.google.com/url?q=https://www.w3.org/2020/10/TPAC/registration.html&sa=D&ust=1603044235646000&usg=AOvVaw36viFX_gauhzNt4g6cGFKW>


   - Add attendance and proposals/ideas/use-cases to the doc


   - HR-time - PR#93
   <https://www.google.com/url?q=https://github.com/w3c/hr-time/pull/93%23issuecomment-704286494&sa=D&ust=1603044235647000&usg=AOvVaw1Ut4wWjHAWPaN11wkXvXpD>


   - Yoav: Spec says timestamp resolution should be at minimum 5
   microseconds (but not less than that)
   - ... In practice, many UAs have coarsened resolution due to
   Spectre/Meltdown
   - ... We would like the spec to allow for different values of resolution
   for different scenarios
   - ... As a result of Spectre/Meltdown we now have the concept of
   isolated contexts
   - ... Which allows us to enable various powerful features such as Shared
   ArrayBuffers, JS Self Profiling, Memory Measurement
   - ... Want spec to say it's OK to be higher resolution than 5us in some
   contexts
   - ... This PR is to change that
   - ... Wanted to discuss value for non-isolated contexts, as different
   browsers do different things
   - ... Don't expect all browsers to align
   - ... Hoping to align on a minimum for non-isolated contexts
   - Michal: You're saying there is a new proposal for isolated contexts,
   but do we want to change the existing 5μs threshold too?
   - Yoav: Suggesting we move non-isolated guideline to be higher than 5μs
   - ... Proposal to keep it at 5μs in isolated contexts, 100μs in
   non-isolated contexts, with some UAs allowed to keep higher values than that
   - Ben: Agreed as a minimum
   - Yoav: Right now if I remember correctly, Firefox is limited to 1ms.
   Is this something Firefox would consider lowering to 100μs?
   - Ben: In the PR, we share our direction, in favor of establishing a
   floor but not a specific value
   - Yoav: Alex?
   - Alex: Our long term plans involve site isolation, but until those
   happen, we are not willing to lower our minimum.
   - Yoav: You're OK with minimum in the spec being 100μs for non-isolated
   contexts?
   - Alex: Lower resolution than 5μs would allow you to see other system
   activity
   - Nicolas: Can you review your values for isolated and non-isolated
   - Yoav: For isolated, 5μs.  For non-isolated, 100μs.
   - Michal: The current processing model uses SHOULD and RECOMMENDS, are
   you proposing a change to MUST be?
   - Yoav: Processing allows for providing coarser resolution than the
   minimum, implementation can provide higher values than that
   - Nicolas: Current spec says 5μs for both cases.  This proposal is, for
   non-isolated contexts, we are increasing the minimum granularity value from
   5μs to 100μs
   - Ben: Is this the last HRTime issue?
   - Yoav: There is an open issue to be better integrated with the DOM
   spec, where they want access to the raw times for internal purposes
   - ... Because L2 is already in REC, we kicked off a L3 editor draft that
   we can link to
   - ... Hoping to turn that in a living standard with a new process and
   charter


   - visibilitychange:hidden doesn't fire during page navigations


   - https://github.com/w3c/page-visibility/issues/59
   <https://www.google.com/url?q=https://github.com/w3c/page-visibility/issues/59&sa=D&ust=1603044235650000&usg=AOvVaw0L9kUjl8XcFpIJp-tJ7Tqs>


   - WebKit bug 151234 – visibilitychange:hidden doesn't fire during page
   navigations


   - Michal: Philip filed the issue RE inconsistencies between browsers
   - … Safari fixed visibilityChange on navigation
   - … Double checked the status, versus original table from a year ago and
   browsers improved
   - … Chrome on Desktop, closing a tab or browser does fire a visibility
   change
   - … Chrome on Android - the app switcher is firing, but the test is
   buggy (localStorage issue maybe)
   - … Remaining difference on Safari - tab switcher or app switcher
   doesn’t fire the visibilityChange event
   - … Video continues to play
   - Yoav: Tested and on Android device, video continues to play as well
   - Michal: Firing hidden may change behavior
   - … May need a third state here? Safari may be likely to keep this
   “visible” to prevent breakage
   - Npm: What’s the use case of a third state?
   - Michal: Clue that it’s no longer interactive, no longer usable, cue to
   send analytics, but since it’s not hidden, you shouldn’t disable animations
   or pause video
   - Ben: How are we describing this in HTML?
   - Michal: Not very well specified ATM
   - Npm: If we fire it when you close the tab from the app switcher, would
   that be a problem?
   - Michal: Tab switcher would work but the app switcher may not give you
   enough time to fire the events. Today on Android, Firefox and Chrome,
   AppSwitcher fired hidden immediately.
   - Npm: But video is still playing from the app switcher
   - Michal: Yeah, and it’s a feature.  We're assuming it's hidden but not
   really hidden.
   - … Maybe the easiest solution to the problem is to still fire
   visibility hidden when the app is killed. But more likely to miss
   opportunities to send beacons.
   - Npm: The main concern is having a way to reliably use the visibility
   change to beacon performance data. No particularly strong use case to
   having a third state, but would be ok with it for a reliable callback
   - Phil: Developers may not be checking for “hidden”, but for "not
   visible”. Is that what you’re suggesting?
   - Michal: Yeah, webkit folks didn’t want to change to hidden
   - Phil: I don't disagree, but it's a concern taht most of the code on
   the web checks if "visibility state is hidden", so adding a new state would
   not help
   - Yoav: Seems like we'd have an incompatibility issue if we went with a
   third state, undesired breakage by tab switcher or may no longer beacon
   their data when it's in effect
   - Michal: Existing browsers that change to beacon will break beacons,
   but we can not ship the new state at first, and only webkit will do that.
   - … The whole point is that there used to be a tri-state (prerender)
   - Npm: Seems worse to have one browser behave differently, using a
   different state name. Need to investigate sending hidden in those cases
   - Michal: On Android, both Firefox and Chrome send visibility change the
   moment you launch tab switcher, but killing the browser fast enough may not
   enable beacons.
   - … We can’t change to that strategy and hope to be as effective. But we
   can try.
   - … Safari also dispatches unload correctly, so maybe we should first
   fire visbility change first
   - Phil: Was related to bfcache, where Safari wouldn’t fire unload if the
   page is BFCache eligible, same direction Chrome is going with its BFCache
   implementation
   - Ben: Can we outline the acceptable solution space? Tri-state?
   - Alex: I haven’t followed this, so not the right person. Tri-state
   doesn’t seem a great idea.
   - Ben: Can we get a quick overview of the last attempt to use tri-state?
   - Michal: Third state was around preloading, put it in anticipation of
   use but wasn't
   - Yoav: Prerendering was the third state, when we would prerender on
   desktop, but that changed to link rel=prerender as a hint to prefetch
   resources but not actually render the page.
   - ... Discussion about Prerender flag's history, how it may be
   potentially revived in Chrome under different criteria
   - Michal: Quad-state would make the disadvantage of tri-state negligible
   - Yoav: Assuming sites actually take all of those states into account.
   We need to maybe gather some data on that front, if we can move from two
   state to something else
   - Nic: Is that something we can easily check usage of in HAR
   - Michal: Look for equals vs. non-equals?  And it depends on the
   context, are you looking for that or the opposite
   - Yoav: I think both equals and not-equals, they're not semantically
   different.  We need people to do if/else on visible/hidden.
   - ... Hidden and "preview" share some characteristics that we may want
   to maintain, and visible and "preview" also share some characteristics
   - ... Add a use-counter for visibility events, and inspect ~100 sites to
   see what would break.  Seems painful, but the only way to do that analysis.
   - ... Or run an experiment to see if people complain, bugs surface, etc.
   - Nic: With all this, what are the best next steps? More data on usage?
   Talk to Ryosuke?
   - Yoav: I don't think it's just an iOS thing.
   - ... If some videos stop when going into tab switcher and others don't,
   maybe we already have a compatibility problem
   - Michal: If any web app is nice with turning off animation and videos,
   they may not realize
   - Yoav: Think we need to do more research here, see if there's already
   breakage in the wild
   - Benjamin: Thanks Michal for the useful discussion. Interested in
   hearing more about prerendering at TPAC


   - Measuring Layout Instability from IFRAMEs
   <https://www.google.com/url?q=https://github.com/WICG/layout-instability/issues/80&sa=D&ust=1603044235657000&usg=AOvVaw07ixXYffSirPUCL0DCzLqB>


   - Nic: Content in iframes could be shifting and affect the visual user
   experience
   - ... the spec suggests that iframes contribute to their parent CLS
   scores
   - ... Proportion as a size of its viewport
   - ... In practice it’s hard to measure this consistently with RUM
   - ... Synthetic tools and RUM don’t account for that. (e.g. Lighthouse)
   - ... My concern is that we need to be consistent with those measurement
   in RUM
   - ... Similar to other issues with iframes, resources/long tasks, where
   in order to get those events you need to register perfobservers on those
   iframes - crawl the tree, etc
   - ... Also, iframes could be created dynamically and deleted, so the
   picture would be missing
   - ... And cross origin iframes make things even harder
   - ... If we can’t easily measure layout shifts in iframes from RUM, we’d
   diverge from synthetic once they fix up
   - ... Bubbles flag proposal would help.
   - ... Second proposal, to opt-in for a cross-origin iframes would also
   help to get info from 3Ps.
   - ... We talked about those solutions - not super controversial, but not
   as much clear use cases beyond ResourceTimnig data. Layout shifts is yet
   another use case
   - ... Should we continue this discussion?
   - Noam: Clarification question - CLS is based on the portion of the
   iframe in its embedder, how is that calculated?
   - Nic: Subframe weighting factor, aka pixel weight
   - Noam: iframe may be partially hidden, and the layout shift may shift
   the iframe itself. So it can change its weight
   - Nic: Talking about layout shifts inside the iframe, not in the parent
   document
   - Noam: Yeah, but the shift only needs to count if the shift is itself
   visible. So need to be weighted based on the iframe’s visible area. But
   layout shift changes may change the weight of other iframes.
   - Npm: Subframe weighting factor is computed on every frame on the
   visible part of the frame, it can change per-frame
   - Noam: Defined in the spec?
   - Nic: *quotes the spec*
   - Npm: CLS is non-normative, as it’s not explicitly exposed. Needs the
   portion of the iframe that intersects with the viewport to compute the CLS.
   - ... Can add a usage example where a frame computes its score.
   - ... But there’s no canonical way to get the score from your iframes.
   - Nic: “bubbles” would enable iframes to surface their layout shifts,
   and maybe also their viewport weight
   - ... Any way of getting these entries is currently a challenge
   - Benjamin: PerfObservers for every iframe makes this more of a challenge
   - Nic: Currently don’t use PerfObservers in iframes for RT for
   Boomerang, because of their transient nature, so hard to get a complete
   picture
   - Michal: Problem with iframes in iframes - is CLS a factor of its
   parent, or the ancestor?
   - Benjamin: Question from mozilla - would bubbling change the buffer
   sizes?
   - Npm: For the buffering, from an implementation standpoint, you could
   pass the existing entries from the other iframes. So would not increase the
   things you need to store. But would require a hop to store those.
   - Yoav: Would that require copying entries?  Entries would be part of
   that frame, and also copied to another process
   - Npm: Would incur a cost if they are used, but not if they are not used
   - Nic: bubbling is not the same as cross origin opt-in, and there are
   two separate proposals.
   - Npm: If you have use cases, concerns, ideas, etc - please chime in

- Nichttp://nicj.net/
@NicJ



On Tue, Oct 6, 2020 at 1:01 PM Nic Jansma <nic@nicj.net> wrote:

> Hi everyone!
>
> On the agenda
> <https://docs.google.com/document/d/10dz_7QM5XCNsGeI63R864lF9gFqlqQD37B4q8Q46LMM/edit?pli=1#heading=h.osvewfb7hvdz>
> for our next call (Thursday October 8 @ 10am PT / 1pm ET) we aim to have
> discussions on:
>
>    - HR Time
>    - visibilitychange
>    - Layout Instability
>
> If you have any additional items you'd like to discuss, please add to the
> agenda
> <https://docs.google.com/document/d/10dz_7QM5XCNsGeI63R864lF9gFqlqQD37B4q8Q46LMM/edit?pli=1#heading=h.osvewfb7hvdz>
> .
>
> Join us <https://meet.google.com/agz-fbji-spp>!
>
> The meeting will be recorded and published online afterwards.
>
> See you soon!
>
> - Nic Jansma
> @nicj
>
>