Re: WebPerfWG call - April 28th @ 8am PST

Minutes
<https://w3c.github.io/web-performance/meetings/2022/2022-04-28/index.html>
from the meeting are now published. Copying here for convenience:

WebPerfWG call - April 28 2022
Participants

   - Nic Jansma, Yoav Weiss, Mike Henninger, Juan Ignacio Biltes, Noam
   Helfman, Pat Meenan, Chengzhong Wu, Marcel Duran, Carine Bournez, Michal
   Mocny, Amiya Gupta, Benjamin De Kosnik, Alex Jose, Nicolás Peña Moreno,
   Annie Sullivan, Ian Clelland, Lucas Pardue, Jeremy Rose

Admin

   - *Next meeting*: May 12th at 10am PST / 1pm EST


   - We'd like input on how the alternating-timeslots (10am PST / 8am PST)
   are working for the group.  A survey is coming.


   - May 26th meeting has holiday conflicts
   - Yoav:


   - Start with UserTiming namespaces, then back to talking about specs

MinutesUser Timing, async tasks and namespaces
<https://www.google.com/url?q=https://github.com/w3c/user-timing/issues/86%23issuecomment-1108045957&sa=D&source=editors&ust=1652178266745321&usg=AOvVaw0fR0Bz80z_iNrBMzXIejmx>

Summary:

   - String and symbol can both fit in the tag types.
   - Generic filtering/clearing methods can be more extensible.
   - Tags can be beneficial to timings beyond user timing, e.g. EventTiming

Minutes:

   - *Chengzhong*: Last time we talked, people were interested in the topic
   - ... Posted some potential solutions in the Github issue
   - ... Today we'll talk about the possible solutions
   -
   - ... namespace to filter out specific events, or to clear out entries
   without prefixing
   - ... The original solution I posted in the Github issue may not be very
   fitting in the current APIs
   - ... Instead I propose a solution where you can specify a namespace or
   tag to a PerformanceEntry
   - ... So it would fit along with the globally registered
   PerformanceObserver
   - ... With the additional tag on PerformanceEntry, a PerformanceObserver
   can now filter to specific tags
   - ... Or with timeline you can now getEntriesByTag() in addition to
   getEntriesByName()
   - ... You can filter out specific entries or clear them (by tag)
   - ... Tag is just a very simple string, and we're filtering by simple
   string matching (strictly equals)
   - ... Start with a simple string management with no namespace or nesting
   - ... Last meeting it was suggested that namespace/tag could have
   nesting, and I think that might be out of scope of this proposal
   - ... We can extend the solution if we get more feedback, e.g. if we
   need tags to be nestable
   - *Yoav*: I like either tag or namespace, but passing on simple string,
   and we can filter based on that -- restricted to UserTiming
   - ... The only part where it's unclear to me is getPerformanceTag() --
   is that a user function or an API call.
   - *Chengzhong*: User function to construct tag in this example
   - *Jeremy*: Could tags be symbols?  Guaranteeing non-collision
   - ... You might accidentally collide with another library if using the
   same name
   - ... Could marks have more than one tab
   - ... Queryable on either an or/and basis
   - ... Should I be able to tag a mark with more than one tag?
   - *Chengzhong*: Symbol sounds good, since it's a valid thing in
   JavaScript
   - ... Symbol might fit in the space well
   - ... I think multiple tags might be useful, but I didn't come up with a
   use-case for it.  Maybe we can discuss more in the thread?
   - *Yoav*: Interesting to find use-cases first before adding complexity
   - ... At the same time think about that in case a use-case comes up
   later?
   - *Chengzhong*: Agreed
   - Patrick (in chat): Component + "level" (debug/critical/timing/etc)
   - *Michal*: Small thing, I think the collision concern is valid, but
   I've used UserTimings from console by hand and it's useful to reference by
   name
   - ... A lot of this looks like convenience, so in terms of write-ability
   I don't know if it's necessary to have a symbol
   - *Chengzhong*: People can use primitive strings if they like, and
   symbols can be unique tags if they find it's essential that they're not
   colliding with others
   - *Ian*: If we do something like this, rather than adding
   getEntriesByTag() could we have a filterEntries that describes a dictionary
   of things you want.  You may want to query by multiple axis.
   - *Chengzhong*: We currently have multiple methods to clear.  I can
   explore the possibility.
   - *Ian*: Maybe the group can explore that?
   - *Yoav*: Looks like PerformanceTimeline more than a UserTiming issue
   - *Nic*: Is this appropriate for other types of entries?
   - *Chengzhong*: Maybe just user timing. Browsers would need to tag other
   entries
   - *Nic*: Maybe with resource timing and Fetch, we could tag your fetches
   in ways that would be reflected. Might be useful for other types of
   resources
   - *Chengzhong*: may be interesting for resource timing
   - *Nicolás*: Just had an alternative thought. Right now it’s hard to
   clear certain types of entries. An alternative could be to allow more
   flexibility when passing the string to clear marks or clear measures
   - …Could clear all the names with prefixes. Wouldn’t work with multiple
   tags. Would require more regex
   - … may be too ugly
   - *Yoav*: One point of excitement about namespaces last time we talked
   about them, was for tools to potentially pick them up and reflect them to
   the user.  Dev tools and RUM providers could show all UT entries related to
   React, or hide all entries related to React.
   - ... We could do that with conventions, but namespaces is easier
   - *NPM*: Yeah that makes sense, sounds cleaner
   - *Amiya*: ElementTiming might also benefit from namespaces.  I don't
   know if it supports clear, but having things coming from a common shared
   component, it might work as well
   - *Yoav*: Would need to squeeze namespace into the element
   - *Amiya*: Pass in a string, room for a tag there as well
   - *Noam*: Reminds me of adding tags to EventTiming APIs as well.  It's
   not exactly the same, but seems like there's some industry request for
   tagging requests in different forms, this is just another one
   - *Yoav*: I think for EventTiming you want almost the inverse, to
   distinguish different events on same element, where here you want to group
   together events that are related
   - *Noam*: Notion of tagging or grouping various entries, seems to have a
   use-case here
   - *Yoav*: What I'm hearing generally is excitement about use cases in
   general shape.
   - ... Might be extensible beyond UserTiming as those use-cases come up
   - *Michal*: With L3 UserTiming we have a `details` object, what could be
   solved?  Is it convenience or performance?
   - *Yoav*: About tools being able to provide users with ways to split
   based on namespaces
   - ... details is just a blob so equivalent to prefixing UT entry name
   - ... We could theoretically attach namespace via convention
   - ... Maybe we need a better generic solution for filtering and clearing
   - ... This would be a more convenient way to solve
   - ... We'll continue to iterate on the issue.
   - *Chengzhong*: Will summarize in issue

Specs to Promote

Summary:

   - ResourceTiming - There seems to be ongoing demand for nextHopProtocol
   beyond protocol migrations. Need to try and resolve the other issues.
   - Navigation Timing - blocked on issue 160
   - Server-Timing, HR Timing, requestIdleCallback - Yoav to figure out
   failing tests and send CFC to publish

Minutes:

   - *Yoav*: Four specs that could move from WD to CR
   - ... One that could move from PR to REC
   -
   - ... ResourceTiming already has a CR transition request for it
   - ... Seems to be blocked on a few issues that have been opened by PING
   - ... One issue is something we've generally discussed and don't agree
   with as a group
   - ... Another issue is which we acknowledged as an issue but haven't
   resolved yet
   - ... https://github.com/w3c/resource-timing/issues/221
   <https://www.google.com/url?q=https://github.com/w3c/resource-timing/issues/221&sa=D&source=editors&ust=1652178266771911&usg=AOvVaw3b1jZF9leBu1BOgW6AbGww>
nextHopProtocol
   may expose things about the user's network
   - ... Puts things behind TAO protection, but it doesn't solve the issue,
   just limits exposure
   - ... At the very least, there aren't necessarily good solutions for that
   - ... Assuming exposing the user is behind a proxy is bad
   - ... One issue PING filed
   - ... Another issue is removing wildcard from TAO
   https://github.com/w3c/resource-timing/issues/222
   <https://www.google.com/url?q=https://github.com/w3c/resource-timing/issues/222&sa=D&source=editors&ust=1652178266773219&usg=AOvVaw3lrh_raDTu5vQFbjUPAdUb>

   - ... We generally disagree with PING's conclusion about limiting
   exposure for issues being resolved elsewhere
   - *Lucas*: I wasn't aware of the issue around nextHopProtocol, there's
   another issue happening in the wave group.  They want to detect proxy usage
   on server-side and send that back to clients
   - ... https://github.com/cta-wave/common-media-server-data/issues/11
   <https://www.google.com/url?q=https://github.com/cta-wave/common-media-server-data/issues/11&sa=D&source=editors&ust=1652178266773953&usg=AOvVaw3yg6q13Fkl7R9Qp1VOKJfW>

   - ... Seems very related.  Some people say it's bad, some people say
   it's useful.  Answer is somewhere in between
   - *Yoav*: Yes and those things may not be contradictory
   - *Lucas*: Having that information in traces is absolutely necessary.
   If you ignore proxies, for people who have an interest in web performance
   we need to have enough information as possible
   - *Yoav*: Could ServerTiming be a replacement?
   - ... In the middle of a migration from H2 to H3, you can paint the
   sessions via ServerTiming, and once that migration is complete, you remove
   the header
   - ... We originally added nextHopProtocol for the H1 to H2 migration
   IIRC, before we had ServerTiming
   - *Lucas*: I'd have to think about it more, but I would trust the
   browser over the third-parties to get that information
   - ... It's not just about a migration, I expect browsers to fetch over
   all the versions forever
   - ... Expect it to be years before that information isn't useful
   - *Yoav*: Do you have insight into how we can unblock this transition
   request
   - *Carine*: Just need to close the issues, PING may have an objection
   with the resolution.  Director would resolve the formal objection if that's
   the case.
   - *Yoav*: From PING's perspective, in their documentation, we're not
   allowed to close issues they opened unless they're happy with the resolution
   - *Carine*: It boils down to formal objection if they're not OK with
   closing it
   - ... We can give them a proposal for closure, and see if they agree to
   close
   - ... To avoid a formal objection
   - *Yoav*: This will require some more thought
   - *Yoav*: Moving on to NavigationTiming
   - ... For all the rest, we haven't requested a transition from WD to CR
   - *Yoav*: Was in CR in the past, but then we want to remove levels, so
   we moved them back to WD and now we want to promote to CR again
   - ... For NavigationTiming, tests are mostly green
   - ... One contentious issue
   https://github.com/w3c/navigation-timing/issues/160
   <https://www.google.com/url?q=https://github.com/w3c/navigation-timing/issues/160&sa=D&source=editors&ust=1652178266777136&usg=AOvVaw2u-g9_2sHLcROv1d8U2jWs>
around
   exposing cross-origin redirects
   - ... As part of CR we have wide review, and I expect this will come up
   as a point we need to settle before moving the spec forward
   - ... For HR Time and ServerTiming, all tests are green (or almost) and
   we don't have any significant pending issues
   - *Nic*: Do we have the requisite number of tests passing for multiple
   UAs?
   - *Yoav*: I think that requirement is just for PR, Carine?
   - *Carine*: Yes
   - *Yoav*: For HR TIME, the only test not passing is around shadow
   realms, which at least from my perspective we can exclude
   - ...
   - ... For ServerTiming, there are a few failing tests in Chromium that
   we can prioritize and fix to unblock this
   -
   - ... I think we can move that forward
   - *NPM*: What does shadow realm test?  Is it about exposing the object
   in those?
   - *Yoav*: I don't think shadow realms has shipped
   - ... It's above exposure of timeOrigin to shadow realms but I'm not
   sure it's well specified
   - ... Something we need to look into to either revert the tests if it's
   not yet shipped, or make them tentative
   - ... Other than that, does moving to CR sound good to everyone?
   - (no objections)
   - *Yoav*: Action item here for Yoav to look into HR Time and
   ServerTiming failures, and once they're fully green we'll file issues
   - *Benjamin*: Would that be a Call for Consensus?
   - *Yoav*: Carine do we do that for CR?
   - *Carine*: Yes
   - *Yoav*: Ok, I'll do homework then send CfC for both
   - *Carine*: Do we want to drop the levels?
   - *Yoav*: Yes
   - ... Finally, for requestIdleCallback, it's been in PR for a while
   - ... We fixed issues around integration with HTML
   - ... Tests are all green except for one
   - ...
   - ... Assuming we can fix that single failing test in both
   implementations, we could move it to REC
   - ... All changes were around better defining deadlines for event loop
   in HTML?
   - ... This would be a CfC to move to REC
   - (no objections)
   - *Yoav*: AI to look into the test and send a CfC

Exposing prefetch
<https://www.google.com/url?q=https://github.com/w3c/navigation-timing/issues/163&sa=D&source=editors&ust=1652178266787564&usg=AOvVaw2DyOeNnG6E7-aLnmxPVf5O>
 and Critical-CH
<https://www.google.com/url?q=https://github.com/w3c/navigation-timing/issues/177&sa=D&source=editors&ust=1652178266788595&usg=AOvVaw3HZ717rxNnxvP4dlqrY6K1>

Summary:

   - It seems fine to expose prefetch and Critical-CH signals orthogonally.

Minutes:

   - *Yoav*: NavigationTiming issues about exposing prefetch and Critical CH


   - ... Conclusion on call when we talked about prefetch and discussion
   afterwards was that it'd be good to be a boolean on ResourceTiming
   - ... Another issue that feels related is on reporting that a
   Critical-CH header would be used
   - ... Client Hints is a content negotiation mechanism, which allows the
   browser to tell the serve about the user's environment, but only for CHs
   that the server requested
   - ... One example is recent UA CH, where specific details about UA such
   as OS Version can be omitted by default from UA string but can be requested
   by server needing that information
   - ... In case server thinks one hint is critical, i.e. content can't be
   served unless it's known, then server can send a Critical-CH header that
   includes a hint it deems critical
   - ... If past negotiation ation didn't get the hint, then that
   navigation gets restarted with an internal redirection
   - ... Navigation is restarted with those hints in place
   - ... Chromium folks got a request that it's hard to deploy Critical-CH
   without knowing that they were used
   - ... Backup mechanism that folks are hoping will never be used, i.e.
   ACCEPT_CH frames should take care of the negotiation before the request was
   ever sent
   - ... For correctness Critical-CH is there, but folks don't know if it's
   used
   - ... This may be another boolean we could expose
   - ... Simple solution would be to expose a Prefetch on RT and CriticalCH
   on NT, but wondering what folks think about that?
   - *Michal*: You say that's the simplest thing, are you concerned this
   will turn into a bunch of booleans?
   - *Yoav*: I don't know, we're also talking about prefetch (boolean) and
   activationStart (timestamp)
   - ... But there is some concern.  One option would be to mint a new
   navigation type, but this is orthogonal as you can have a e.g. Reload with
   a Critical-CH header
   - *Nic*: I think this is novel, useful information.  No concerns around
   it being more booleans on data
   - *Ian*: Should some of this be on the ResourceTiming entry?
   - *Yoav*: Client Hints are only suitable for top-level navigation
   - ... I don't see how it'd be useful outside of a navigation response,
   at least in its current form
   - *Nic*: Confirm that this boolean would expose that the Critical-CH
   triggered a restarted nav, not just that the header was on the response
   - *Yoav*: Yes



On Wed, Apr 27, 2022 at 6:27 PM Yoav Weiss <yoavweiss@google.com> wrote:

> Hey folks,
>
> Let's meet up <https://meet.google.com/agz-fbji-spp> tomorrow to talk
> WebPerf!!
>
> On the agenda
> <https://docs.google.com/document/d/10dz_7QM5XCNsGeI63R864lF9gFqlqQD37B4q8Q46LMM/edit?pli=1#heading=h.7t9hc9bw5psn>
> we have:
> * Conversations about moving various specs further on the REC track
> * User Timing and namespaces
> * Prefetch and Critical-CH indicators on Resource/Navigation Timing
>
> And maybe a few more issues. If there's anything you'd like to discuss,
> feel free to add it to the agenda.
>
> See y'all there! :)
> Yoav
>

Received on Tuesday, 10 May 2022 14:56:59 UTC