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

Minutes

User Timing, async tasks and namespaces

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 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
... 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
... 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 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 and Critical-CH

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