Participants:

Dave Pifke, Michal Mocny, Steven Bougon, Nic Jansma, Gilles Dubuc, Yoav Weiss, Nicolás Peña, Philippe Le Hegaret, Annie Sullivan

Next Meeting

Event Timing Updates from Nicolás Peña

Presentation

Nicolás: 2 API objectives:

… Non-objectives include:

Yoav: With regard to async performance, we discussed measuring how long the paint took afterwards, right?

Nicolás: Guidance is to use UserTiming for measuring your async work, since your JS will already be running in the event handler. That was the conclusion in previous discussions. Also, it’s hard for the UA to keep track of causality of async work.

… *continues presenting*

… First Input - always exposed: From key down, mouse down, pointer down + pointer up, click

… Also expose "general input delay" from a list of non-continuous events whose duration is > 100ms (104ms rounded)

Steven: If one of those events takes less than 104ms, we won't be notified?

Nicolás: Correct

Steven: For the gaming industry, would they want to have a lower threshold?

Nicolás: It's feasible we could let the threshold be variable pending security + privacy review.  Only challenge is we support the buffered: flag, which means we'd have to store the lowest possible threshold. Also don’t want to make the threshold too low as that would be spammy

Steven: Makes sense as a default, but might be good to have an option

Yoav: For the buffered case where you care about faster clicks, you've probably already setup the app and have registered your observers, so the buffered could just deliver the default threshold, and we’d deliver values with lower thresholds only when explicitly required

Nicolás: Possible, but might be confusing to developers.

Dave: For those that want to only track a higher threshold, it would be easier since the buffer could just deliver those under the threshold

Nicolás: Yeah, we can add a parameter

… *continues presenting*

… What's exposed

Yoav: Is there an easy way to detect which types are supported for observation?

Nicolás: Will make sure we have something available

… Chromium shipping First Input Timing

… Chrome intends to ship Event Counts as well as full Event Timing in near future

… [goes over PerformanceEventTiming interface in slide deck]

Yoav: `name` is the event type rather than URL like other performance entries, right?

Nicolás: Yeah.

Yoav: `cancelable` is a way to track passive events vs not, right? That enables distinguishing events that have to run sync vs. not. Seems like something we want to make people aware of. Mostly relevant for scroll events, so maybe not so relevant. Worthwhile to think about developer advice here.

Nicolás: Makes sense

... EventCounts interface will give you the number of events that have been dispatched, per type

... For events that are not supported by the UA, they could be optional. That would enable feature detection

Philippe: Why not a map object?

Nicolás: Not sure why. I’ll look into it

Steven: Other groups looking into user behaviors may be interested in a number of clicks. Wondering if we can expose that?

Nicolás: Event counts would give you the total number of events

Nic: Event Counts mentioned that the counts would be updated asynchronously, I would just want to make sure the counts are relatively in-sync with when the PerformanceObserver is dispatched, so the EventTiming entry is reflected in the EventCounts by then

Nicolás: Some UAs may filter unhandled events outside of the renderer process, so the count would have to be asynchronous. But there should be some guidance that if the performance entry is dispatched, the count also includes it. Makes sense and sounds feasible.

Issue Triage - NavigationTiming

Better integration with ResourceTiming

Nicolás: Spec language is confusing, as the NT spec (which uses same-origin for exposing some times like DNS) links to the RT spec (which uses TAO for the same times), plus additional spec confusion

Yoav: Mark as blocking for L2. Will go away in L3

Nicolás: Need to make sure that the checks make sense

Nic: In navigation timing, those entries are always exposed right?

Nicolás: Can have cross origin redirects for the navigation

Nic: Yeah, but it’s always exposing the last entry

Yoav: So for NavTiming, TAO on its own origin always passes.

… But seems reasonable to make sure someone goes over that and verifies that the behavior is what we want it to be

Can hitting enter on address bar to same URL be considered a navigation of type 'reload'?

Yoav: WebKit folks had a few examples where it’s not a reload, e.g. when navigation was made with a POST

Nicolás: Need to define reloads in terms of what the UA is doing, not user actions. So this is blocked on HTML

Yoav: Agree. We can mark spec as blocking, pointing to "reload triggered navigation", and open a HTML issue on better defining what that means.

Surface chunk network timing details

Yoav: Useful addition, but seems like a feature request for Level 3

Nic: RUM customers haven't requested this yet, but could be useful

Yoav: This type of data is now being surfaced in WPT and used to expose bad server behavior

Nic: More visibility would be useful.

What should transferSize, encodedBodySize and decodedBodySize in Navigation + Resource Timing represent for responses where a Service Worker is involved?

Current implementation on latest builds of a number of popular browsers (Chrome, Chromium, Firefox, Edge, Samsung Internet) seem to allude to this fact by simply reporting a "0" for all these parameters when a Service Worker is involved in between

Nicolás: Do we have a sense of what those properties be with a SW? Or should we talk about it with SW folks?

Yoav: Would be useful to talk about it in terms of SW use cases

.... From a security perspective, can a SW add TAO to a cross-origin response? Can’t do that as it’s an opaque response. So that’s probably fine.

Yoav: Marked as Level 2 blocking because it seems like we need to answer that question