Re: WebPerfWG call - June 10th 2021 @ 10am PT

Minutes
<https://w3c.github.io/web-performance/meetings/2021/2021-06-10/index.html>
and recording <https://youtu.be/c8PJ8W97_M4> are now available, and
published to Github
<https://github.com/w3c/web-performance/tree/gh-pages/meetings>:
Participants

Giacomo Zecchini, Nic Jansma, Yoav Weiss, Patrick Hamann, Annie Sullivan,
Steven Bougon, Michal Mocny, Nicolas Pena Moreno, Sean Feng, Carine
Bournez, Benjamin De Kosnik,

Next Meeting - June 24th 10am PSTMinutes

Nic: Plan for today is triage.
web-performance #36: Add pull request template
<https://www.google.com/url?q=https://github.com/w3c/web-performance/issues/36&sa=D&source=editors&ust=1624571865965000&usg=AOvVaw0XaKuon-TFXRit4dP5QtNX>

   - Nic: Marcos suggesting a PR template for all repos. Has a suggested
   template in https://github.com/w3c/hr-time/pull/121/files
   <https://www.google.com/url?q=https://github.com/w3c/hr-time/pull/121/files&sa=D&source=editors&ust=1624571865965000&usg=AOvVaw19Gt2EkuHCWtEKsvisMnPr>
   - ... Starting point for pull requests. Thoughts on things included?
   Other things we should add?
   - ... Will propagate that throughout the repos
   - Nicolas: Maybe a field for PRs that are not implementation changes?
   - Yoav: “editorial” vs. “breaking change”
   - ... Maybe we can add “change” vs. “breaking change”
   - ... Different field for backward-compat that requires more significant
   input
   - Nicolas: Need to make the difference clear between “chore” and
   “editorial”. We should add a short description.
   - Michal: Should have commitments before opening a PR?
   - Yoav: No, need to have it for landing for changes and breaking changes
   - Michal: I don't want anyone to not open a PR because they don't have
   commitments yet
   - Nicolas: Top says this is only for normative changes. Unclear where
   editorial and chore fits.
   - … Also want to not discourage people from submitting PRs. Need to
   clarify what fields are not require for submitting the PR.
   - Nic: Captured all in a comment on the issue. Once we get it merged in,
   we can duplicate it further.

App History #124: Introduce performance timeline API integration
<https://www.google.com/url?q=https://github.com/WICG/app-history/pull/125&sa=D&source=editors&ust=1624571865967000&usg=AOvVaw3ndcJ7NlipTRTqT-1XCztx>


   - Nic: Talked about new types of navigation, this App History API allows
   you to specify Soft Navs
   - Yoav: For some background, Domenic and others are working on a new App
   History API that allows better control over what a Soft Navigation is, and
   enables the browser to know when an intent for Soft Nav is happening
   - ... Today developers intercept a random click event and pushState a
   random URL change, there's no clear way to say a navigation has started or
   ended
   - ... App History gives clear time it was started, whether it was
   user-initiated or not
   - ... Includes a promise-based API developers can resolve whenever they
   feel it has been completed
   - ... Domenic suggest a new PerformanceEntry,
   SameDocumentNavigationEntry, just has a boolean success
   - ... Time difference between start time and when it was resolved
   - ... A lot of the attributes for regular navigations aren't aren't
   appropriate for Soft Navs, e.g. network timings
   - ... At the same time similar for BFCache navigations, we were trying
   to have all the same nav types need a single listener
   - ... Do we want separate observers for separate navigation types?
   - ... One option that Domenic mentioned that could be interesting, is a
   single keyword that allows you to navigate all of those different
   navigation types, but still entry types for each
   - Nic: For clarification, instead of .observe(navigation) you would do
   .observe(all-navigations)
   - Yoav: Yes, you could do that or .observe(bfcachenavigation) or all
   types
   - ... From back-compat, we looked at extending navigation array and it
   is web-compatible, but it's possible some of that code looks at
   PerformanceNavigationTimingEntry and will get confused if it other types
   are in the array
   - Michal: If the goal is throwing them into a single bucket only to know
   when it's time to slice all entries, but then visibility- or idleness- of
   sessions gets thrown in.  If not, if it's narrowly focused on navigations,
   the difference between BFCache and AppHistory is the URL changes.  And
   there's one property I would want to handle specifically for BFCache.
   - Yoav: I think slicing isn't the reason here as we can have Navigation
   IDs with a counter that tells you for other entries which Navigation ID it
   correlates with.
   - ... Hadn't considered adding visibility to having a new Navigation ID,
   but it doesn't necessarily impact the API shape
   - Michal: Is it possible to get the URL in the case of a App History
   navigation?  I didn't see it in the proposal
   - Yoav: Yes, I hadn't seen URL as part of the entry.  Entry should
   provide that attribution, meaningful for developers that are collecting it
   - ... I haven't heard any strong opinions on API shape
   - Yoav: AI for anyone with an opinion to go to the PR and comment
   https://github.com/WICG/app-history/pull/125
   <https://www.google.com/url?q=https://github.com/WICG/app-history/pull/125&sa=D&source=editors&ust=1624571865969000&usg=AOvVaw2shb6LjvXYzVBMj571nnPz>
   - NPM: Is the idea to also surface this for back-forward navigations?
   - Yoav: Different from SameDocument, we would use a different type for
   BFCache navigations
   - ... Either we take that shape for SameDoc navigations as well, or
   BFCache is yet another navigation entry
   - NPM: This and BFCache navigations seem similar in the information we
   would provide
   - ... Most attributes for regular navigations are about network
   - Yoav: This currently provides a success boolean, and it should provide
   a URL.  Duration defined on the promise, where I'm not sure BFCache should
   provide a duration.
   - NPM: I guess we need to answer that question, do we need same entry
   for App History vs BFCache vs regular nav vs Portal navigation
   - Yoav: Yeah that is exactly the question
   - Michal: Beyond downside to having to register multiple observers, if
   we're going to register Navigation ID for all, you would need to monitor
   for all to be correct.
   - ... And do we need a Navigation ID or just a timestamp?
   - Yoav: Times can overlap, we want an ID if possible
   - Michal: If at all possible the ID was the index into all
   - Nic: Future-proofing by having them all in a single observable array
   is better than telling developers to listen to A B C types and then us
   later adding a D type they're not listening to.
   - Yoav: Tradeoff of visibility vs. fitting all navigations into a single
   type
   - AI: Open a new issue in NavigationTiming or PerformanceTimeline to
   coalesce different types


   - https://github.com/w3c/performance-timeline/issues/182
   <https://www.google.com/url?q=https://github.com/w3c/performance-timeline/issues/182&sa=D&source=editors&ust=1624571865971000&usg=AOvVaw0A4aLJNEx_6PP14k6m8B8h>

RT #273: Exposing Early Hints preloads to ResourceTiming
<https://www.google.com/url?q=https://github.com/w3c/resource-timing/issues/273&sa=D&source=editors&ust=1624571865972000&usg=AOvVaw3F2bysX75hSYczjSw1Of6J>

   - Yoav: Proposal is to use initiatorType and have value of initiatorType
   be early-hint
   - ... Has side effect of being transparent from RT spec perspective, it
   just needs after Fetch integration for the caller to Fetch to pass-along
   early-hint as initiatorType and that will be reported
   - ... I think it's a good solution to that problem
   - ... Background is Chrome is playing around with early-hints Origin
   Trial
   - ... One of the requirements is to be able to measure if early hints
   were used, as part of Origin Trial
   - ... Doesn't involve a spec change here, just in Early Hints
   - ... If OT is successful, and Chrome decides to implement and ship,
   this is the right way to report
   - Nic: Is there any info lost from initiatorType when using it here?
   - Yoav: initiatorType is not super useful here, i.e. for Preload it's
   reported as LINK
   - ... No information loss
   - Sean: When I was looking at this the concern I have is Early Hints is
   a Chrome-only feature, exposing something that only exists in Chrome sounds
   like no the right solution
   - Yoav: EH is no browser feature yet, it's an IETF standard, but no web
   spec for it at the moment
   - ... I know the Chrome loading team is planning on working on one
   - ... Needs Fetch integration to see how it interacts with CSP and other
   things
   - ... Right now it's in an Origin Trial, being experimented, not yet web
   exposed
   - ... When its' web-exposed, the current typing of ResourceTiming aligns
   well with the caller passes along to the algorithm what the initiatorType
   is, so this doesn't require any real changes on the RT front.  Just caller
   to Fetch spec.
   - ... Supplemental feature for H2/Push
   - ... Basically the Chrome Loading team is playing around with it to see
   what it gives
   - ... The experiment would enable various partners to report back
   performance improvements or otherwise
   - https://datatracker.ietf.org/doc/html/rfc8297
   <https://www.google.com/url?q=https://datatracker.ietf.org/doc/html/rfc8297&sa=D&source=editors&ust=1624571865975000&usg=AOvVaw1F0ms82IzYmMqdkdlE4Bc9>
   - AI: Yoav to close the issue since it'll happen in Fetch

RT #274: Use ByteString for nextHopProtocol
<https://www.google.com/url?q=https://github.com/w3c/resource-timing/issues/274&sa=D&source=editors&ust=1624571865975000&usg=AOvVaw3GjsTAPlGMGHwWvo54j-8k>

   - Nic: Opened by Anne, to use ByteString as part of the IDL
   - … In our spec nextHopProtocol requires an isomorphic decode and
   changing the IDL to a ByteString would avoid that extra step
   - Yoav: Can take an AI to see what it actually means

RT #275: No mention to WebIDL in conformance section
<https://www.google.com/url?q=https://github.com/w3c/resource-timing/issues/275&sa=D&source=editors&ust=1624571865976000&usg=AOvVaw02BtexKdYPXFVDOw1NPn-D>

   - Yoav: AI to talk to Marcos and see what that means
   - Nic: Marcos is suggesting that the change was intentional

Fetch #1221 (RT): TAO check and child frame navigations
<https://www.google.com/url?q=https://github.com/whatwg/fetch/issues/1221&sa=D&source=editors&ust=1624571865976000&usg=AOvVaw2JDT6X4pt1M8akZxUgaTd0>

   - NPM: How it's improperly specified for NavigationTiming and IFRAME
   resources because they go through different navigation path in Fetch spec
   than other resources
   - ... Because they start as a navigation
   - ... I think we agree what the thing needs to do, we just need to
   specify if
   - ... It shouldn't have a different behavior than say an IMG, i.e. go
   through all redirect hoops
   - ... Unfortunately we don't get that for free in Fetch because IFRAMEs
   go through a different path
   - ... From when we made the move to the TAO check in the Fetch Spec, and
   we haven't yet fixed it
   - Yoav: For NavigationTiming it doesn't matter because TAO doesn't
   apply, but for IFRAMEs need to report TAO to the parent
   - NPM: Hopefully implementers are implementing it like Chrome does which
   is to not treat it like a different case
   - Yoav: I don't think we have test for TAO checks for IFRAMEs
   - NPM: Maybe that's the first step, to see how browser vendors are
   aligned
   - Yoav: Change but not a breaking change
   - ... Agree if we are all aligned that would reduce the urgency
   - ... I think the TAO tests are not using IFRAMEs
   - ... They're using sync XHR for some reason
   - ... There's an ongoing effort to improve the tests, I think part of it
   is we want to expand the test surface to check different types of resources
   - ... Images at least in Chromium are different types of loaders and
   IFRAMEs are different beasts
   - ... First step is to expand tests to also cover IFRAMEs
   - ... See how big problem is
   - Nic: Any volunteers to work on tests?
   - Yoav: FWIW I think it will be easy
   - ... New test framework for all the old TAO tests are now this list of
   tests and using sync XHR, testing the IFRAME case would just add an array
   here of adding loading functions and iterating over that array with test
   cases
   - ... Results should be the same
   - Nic: AI on Yoav or Nicolas to see if their teammate's refactoring work
   will be covered here, if not someone in the WG can help




On Wed, Jun 9, 2021 at 4:49 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 June 10th @ 10am PT / 1pm ET) we will discuss:
>
>    - Spec/repo updates (e.g. proposed Pull Request Template)
>    - App History API and PerformanceEntrys
>    - Issue triage for Fetch, ResourceTiming, etc
>
> Plus any other issues you want to talk about. If you have additional
> items, please add them 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>!
>
> This meeting will be recorded, unless there are objections.
>
> See you soon!
>
> - Nichttps://nicj.net/
> @NicJ
>
>