Participants

Mike Henniger, Yoav Weiss, Nic Jansma, Pat Meenan, Dave Hunt, Noam Helfman ,Ian Clelland, Hao Liu, Mike Jackson, Sean Feng, Carine Bournez, Tariq Rafique, Barry Pollard, Michal Mocny

Admin

• Next call - June 20 8am PT, 11am ET
• July 4th, no call!
• TPAC - gonna get a pulse RE masking policy (mask, not mask, or optional). Will send an anonymous survey

Minutes

SW static route timing - Ian Clelland

• Recording, slides
• Proposal to add a couple of timing points to RT and NT
• SW static routing shipped and people start using it
• … Aimed to fix perf issues with SW start up time
• … Current RT diagram
• 
• … you define URL patterns and strategies to deal with them
• … and then we don’t even have to initialize SW for these request
• 
• 
• … fetch event - full SW path
• 
• … can say to race network and the fetch event
• 
• … Chrome shipped for 3 months, WebKit and Mozilla are positive of this
• … Want to give this visibility
• … Want to expose when static routing starter, who won the race, how slow was the cache access
• … Raised in Add service worker static routing API information to resource timing (RT 389)
• … Proposal to fix this: https://github.com/WICG/service-worker-static-routing-api/blob/main/resource-timing-api.md
• …
• … The explainer goes into more details about what these points are
• … Hoping that adding those are possible
• …
• … finalRouterSource will tell you who won the race.
• … Should we expose more things about what the SW did?
• … On a cache hit there’s no fetchStart, and that’s different than anything we’ve done before
• … Should we report zero? Omit fetchStart? Something else?
• Nic: A couple thoughts. Great to surface this stuff
• … customers would want to understand the world.
• … fetchStart from a compat point of view, it seems like it should be aligned to responseStart, rather than being zero, which indicates the time origin
• … I’ll provide that feedback on the issue as well
• … RE the finalRouterSource when there’s no matched source, can there be multiple fetches?
• Ian: We’d only see one fetch
• Barry: Raising awareness to NavTiming 199. We shouldn’t add more stuff on top of stuff that don’t currently work
• … Timing is inconsistent when the page is controlled by a SW
• Ian: Maybe we can use this to expose more information about the workings of the SW. It’s currently rather opaque. This would expose when did the worker get the fetch, went to cache, etc
• … So maybe a good opportunity to expose more
• Barry: There are some interop issues, maybe need to clean up the spec
• Yoav: it’s possible the implementation pre-dated the current spec, and all we need is alignment
• … Hoping we have tests showing those inconsistencies
• … Good step toward syncing them up
• Ian: We have manual tests that show this, not WPT
• … Philip tried this and reported back on what he found
• Pat: the cache and race are a shorthand for things that the SW would’ve do on its own anyway, my preference would be that the shorthand version behaved the same as when a SW does the same things
• … Either we add transparency to SW or not expose ore here
• … Otherwise, is it useful for the page to measure the time between the router start and when the router decides what to do?
• … It tells you it went through a router and can tell you how much overhead using routers is adding to your fetches, but how useful is it to web expose this? Maybe browser internal?
• Ian: Tells you that you went through a router
• Pat: But the match and final match also tell you that?
• Ian: Depends if we disambiguate the cases where you weren’t using the static routing API vs. you added routes but none matched this particular fetch (in which case we’d have an empty string)
• … You’re suggesting we can disambiguate those alternatively and drop the router times?
• Pat: Potentially. Adds more numbers that sites have nothing to do about
• Ian: Maybe if you have thousands of routes that would increase that time and be actionable?
• Pat: true
• Ian: The other thing, we want finalRouterSource to do the same thing between regular SW and static router. Maybe worth bikeshedding the name to make it something more useful for SW.
• … All names are up for bikeshedding
• Nic: would be nice to also prefix the router source attributes with “worker” to make their role clearer
• … Feedback on the issue!!
• … We’d try to summarize the comments in the issue itself
•  How to get correct connectStart/End, domainLookupStart/End value when service worker is enabled? (RT 363)
• Nic: The original reporter was noting that RT with SW resulted with connectStart,etc were identical to the workerStart, masking those
• … Yoav suggested that the timings are available inside the SW’s RT
• … Noam suggested to magically bring over the SW entries into the page
• … That might mean that their timestamps predate the navigation’s time-origin and hence negative
• Barry: My understanding is that they’d have a different time origin
• Nic: Noam proposes to bring them to the time origin of the client, so the page
• … That would solve the OP’s question about getting this data
• … You could do this by posting the data from the SW to the page, but there are ergonomics and deployment issues with that
• Barry: I don’t like the name “original entry”, as SW could prefetch things. “Worker entry” would work better
• Nic: the only downside I can think of is the cases of negative timestamps. None today, and this would be a precedent
• … No compat concerns but would still be a precedent
• Yoav: This seems very useful, similar to things in the static route proposal from earlier
• … I feel like Barry’s comment around NT 199, there are current inconsistencies as well as underspecifications when it comes to service workers and timing reports
• … Worthwhile to think about all of these wholistically
• … Wouldn’t want to tackle all of these in isolation
• … Negative timestamps seem fine if they’re not fine, we can clamp to ‘0’
• … We’ve taken that approach for Preconnects, don’t have a strong opinion either way
• … New code can deal with negatives
• Nic: What would be the best approach?  Workshop?  Smaller group?
• Yoav: Maybe brainstorming earlier in the day, so TYO folks can join?
• … Find a time slot that works?
• … Regular WG meeting dedicated for this, but in a different timezone slot

Navigation confidence

• Mike: Would love feedback on the issue and the proposal
• … feedback #1 need the epsilon exposed, working on adding on it
• … Heard from folks that they want to know “why it’s low confidence”
• … I’d love feedback
• Yoav: Can you expand on the use case for a “reason to low confidence” signal?
• … Are there cases where we’d keep a measurement even if it’s low confidence?
• Mike: It gives them another way of breaking down data on their side
• … e.g. if extensions were interfering on the page and causing things to be slow
• … e.g. Maybe a warning popup to turn off extensions
• Yoav: In this case, because we’re talking about probabilistic metric, it’s not something you can do something with immediately on the spot, because you could have a low confidence, i.e. throwing warnings on people with no extensions some % of the time
• … Good to dig into those use cases and understand where folks are coming from
• Mike: Sure, extensions is one part of it, I can ask around for more information
• Yoav: A use-case would look like, if it’s low-confidence because of extensions we still want to collect it, and have a different dimension of users-with-extensions we can’t do anything about, vs. users who are building chromium in the background
• … Then we expose those different dimensions which IIRC feasible but will require higher epsilons (lower fidelity results) so there’s a trade-off
• Mike: If we were to introduce a reason, the confidence field becomes less reliable, as there’s more data that needs to be flipped
• … Original proposal had GPU state, CPU state, etc
• … 500x different combinations of things
• … Now there’s confidence bit, and reason why it’s low confidence
• … So amount of states in that world would be smaller
• Yoav: If that’s a bit, and you can communicate two things, it all comes down to use-cases
• … Good to understand how this extra bit would be used
• Mike: Ask for folks to provide feedback in Issue
• Michal: I left feedback on the thread about naming, special name or wrapper.  Make it obvious it’s not a discrete value
• Mike: Will push and update to the disclaimer

Extending 'Recommended mark names' to allow user agents to detect media timeouts (UT 110)

• Nic: Extend “recommended mark names” which we had in the past and discussed recently
• … Wants marks around media timeout that would allow UAs to collect metrics around media metrics
• … Remember Annie wanted to resurface some of those
• Ian: We do have “recommended mark names” in UT
• Nic: I think we had it, removed it and re-added them
• Ian: added 7 months ago, as signals that developers provide to Chrome for it to gather statistics
• … At some point we’d need a registry inside the spec
• Nic: Not something that anyone needs to use, but it can give signals to devtools or to browser vendors that something “semantically standard” happened on the page
• … This is a different case, as it would indicate an error. Slightly different use case
• … Anyone interested - please add to ticket
• Yoav: Interesting to think through the use-cases and what browsers can do about this
• … Do we know which UserTimings Chrome is detecting, and reporting to CrUX or internally?
• Ian: I don’t know currently
• Yoav: Useful to know if it’s worthwhile to add more things to this pile
• … even if it’s just used internally to make the browser better
• … Or if it’s just adding details to a registry (which isn’t costly)
• Michal: We might be triggering use counters in Chromium
• … List of specific features that were added to by framework authors
• … Exposed publicly by use-counters
• … Main one I found
• Yoav: Maybe use-counters the HTTP Archive is a consumer of that
• Benjamin: Wanted to point out that the use-case for this is MediaTimeout, and the reference API is getVideoPlaybackQuality, and another part is obsolete.  And not sure how these parts fit together?
• Yoav: This WG may not be familiar with any of this
• … Potentially we could collab with folks working on these APIs to have UserTiming define mark that relates to their APIs
• … At the same time if there’s already clear API feedback from actual API, browsers can add use counters w/out requiring any developer intervention
• Ian: I think the use-case for these recommended names is where website has additional information about what’s going on that the browser can’t infer
• … e.g. Page is Visually Complete
• … Or fatal Media Timeout
• … Browser can’t get this information from just API use
• … Case where site needs to tell UA that something happened
• … Seems like a reasonable proposal, and we can allow things like this
• Yoav: Makes sense just not familiar enough to know about this API
• Benjamin: Might be useful at TPAC w/ cross-group collab