Participants

Nic Jansma, Yoav Weiss, Noam Helfman, Giacomo Zecchini, Noam Rosenthal, Patrick Meenan, Michal Mocny, Peter Perlepes, Michelle Vu, Sean Feng, Gilles Dubuc, Nicolás Peña Moreno, Benjamin De Kosnik, Annie Sullivan

Next Meeting

March 18 @ 10am PST / 1pm EST

Topics

Resource Timing Fetch integration - Noam Rosenthal

Noam R: Up until now, ResourceTiming specifies at which points during network request response the measurements will take place
… Creates parallel algorithm to what already exists in Fetch
… What we’re trying to do is define in Fetch when metrics should be taken
… In some cases this might be vague or open to interpretation
… Trying to make this more precise
… Also some timestamps in HTTP (TLS, DNS, etc)
… Having Fetch gather the metrics and pass to ResourceTiming to normalize before it’s exposed to web developers
Yoav: A lot of the processing model and the somewhat conflicting “getting” algorithms will mote to a structure in Fetch that contains that information, and will report that info to ResourceTiming spec
… Design that’s much closer to how implementations currently do that (at least for Chromium and Webkit)
… Good way to make spec closer to what implementations do
… In the process, there’s scrutiny around what they’re exposing. Hoping to find ourselves with all the attributes well-defined regarding what they expose.
Nic: NavigationTiming is built on top of Resource Timing. Are we planning to also tackle that? Or is that phase 2?
Noam R: That will be in Phase 2. We’re starting with Resource Timing. A lot of the infrastructure would be similar.
Nic: Is the goal to try to maintain compatibility to how we report timing today? Will there be browsers closer to the Fetch-based version than others?
Noam R: I think it will be somewhere in the middle. We want the timestamps to be well defined, to avoid interoperability issues, and we want WPTs to reflect that.
… If there are parts in implementation that can be reverse-engineered to be well-defined, that would be pretty close. In other cases, it might be better to change implementations.
Yoav: We can definitely not break content, but in terms of timing there are MAYs or things open to interpretation, that we’d want to clamp down.
Nic: There’s already divergence in implementations. If there’s anything we need to redefine, I just want us to be transparent about that, e.g. for older browsers vs. future browsers.
Noam R: A lot of things so far are around Timing Allow Origin, and what is exposed. Or under-defined things like workerStart
Yoav: workerStart will be discussed soon, as well as nextHopProtocol should be TAO protected

worker start needs to be added to diagram · Issue #128 · w3c/navigation-timing - slides

Nic: relevant for both NavTiming and ResourceTiming
… Nebulous term capturing when a SW was started
… Was meant to measure the costs of starting up a SW
… Added to the spec in 2015. Implemented only in Chrome, attribute exists elsewhere but always 0
… In Chrome it’s always less than or equal fetchStart
… kinda happens ahead of redirects
… It’s kinda confusing what it means and what we intend to do with it
… It’s missing from the diagram and there’s an open issue on that
… I started looking into where it should fit and there are a bunch of edge cases where if it would be implemented as specced it would be not what we want
… For example, if you have same origin redirects => workerStart will always 0
… If we didn’t do that, workerStart would always be for the last document
… Cross-origin redirects result in time for the cross-origin document and not the final document, and that information we want to avoid
… Also same origin means is different when there are no redirects
… There are also some questions on when workerStart should be in the diagram - before fetchStart or after it?
… fetchStart is after all the redirects but before AppCache
… workerStart happens before that, before the redirects - when the worker had to start up
… But according to the definition, it’s actually the opposite. So some definitions indicate that it should be after fetchStart.
… General consensus about it happening before fetchStart, but inconsistent today.
… The original goal: how do I measure how long it took for the sync service worker to start up?
… Original PR describes fetchStart-workerStart gives you SW start time (at least in mPulse)
… You can’t actually use it that way if there are any redirects, so that would also include redirect time
… There are also SW scopes, so you could have multiple SW starting if you have redirects between different paths on your origin
… So there’s a proposal to change this to have a “worker ready” timestamp, so you can definitely say how long startup took
… Could be confusing if you have multiple scopes
… Not using the same words as Resource Timing, so maybe should work closer with Noam
… There’s also very little test coverage
… Definitely want to lock it once we make changes
… Today it would be hard for Mozilla or Safari to implement because of that
…
… Some of the cases are addressed as well
… But still some other cases that are not yet addressed
… Would make sense to integrate all that with Noam’s work on Fetch integration
…
… Wanted to bring everyone up to speed and see if we need to merge it
Noam R: Something that came up while you were talking about redirects. Everything in Resource Timing has a 1-1 mapping with the request. But here you want to count multiple times the worker starts
… I wonder if it should be a separate entry. Maybe the worker start is not part of the request in a way
Nic: If all we want to answer is SW start time, maybe we can expose that directly.
… In RT we collapse redirect reporting. You could have SW start at different points in time. So maybe it makes more sense to have a workerStartupTotalTime
Noam R: yeah, otherwise you’re counting time for redirects
Benjamin: So great to see this effort. Mozilla just started looking into and Service Worker profiling. We start it after fetchStart. We have this thing called FetchEvent, synthsizes response and the beginning of AppCache.
… Really like the bracketing approach, but there can be different things. Taking what Noam says to heart, and wondering if we need a more fine-grained approach.
Nic: Confusion today on where workerStart falls depends on your definition of fetchStart.
… In some cases it’s the entry point to the Fetch spec, and then workerStart is after fetchStart. In Resource Timing fetchStart is more at a later point.
… Reporting total worker startup time would get around those issues as well.
Noam R: It makes sense that when there are things that are not 1-1 with requests, we have new entries for them. If we have 3 workers, why not have an entry for each one?
… Trying to aggregate them into an existing entry makes it complex.
Nic: Would help with debugging if one of many was slower than others, you can figure it out
Noam R: Can imagine doing this with dedicated workers as well
Nic: and similarly, same-origin redirects could use the same breakdown
Yoav: We’ve had an open issue about that for same-origin redirects. Could be interesting to think about this as a separate problem.
… Thought of inviting folks from the Service Workers WG and have a joint meeting.
<administrative talk about scheduling>

`timeOrigin` is not clamped · Issue #105 · w3c/hr-time & PR#106

Yoav: timeOrigin is not clamped and is exposing the raw time
… No particular vulnerability we found with this, but no use-case either, so seemed healthier to just clamp it
… PR 106
… If any objections, please chime in on issue

Make nextHopProtocol TAO protected

Yoav: Better to make it TAO protected
… Some issues if we don’t, seems safer to
… If objections, please chime in on issue

Event Timing and Scroll Timing - Nicolás - slides

Nicolás: Wanted to talk about how we’re thinking of improving responsiveness metrics
… FID brief recap - delta between event timestamp and the time that event handlers for it begin running.
… Some successes: encourage people to break up their long tasks
… Tap delay issue surfaced
… A lot of sites have this issue (some sites have fixed using mobile viewports)
… Chrome is planning on getting rid of the delay for some of the existing cases
… Want to improve FID: aware of its limitations
… Consider more than just first input
… Potentially include scroll begin
… Evaluate a large chunk of end-to-end latency
… For evaluating more than just the first, multiple associated events
… Keyboard up/down
… Taps or drags with pointer/touch/mouse/[start|end|up|down] + click
… For tap interaction, what is the tap latency
… For drag, just the drag start/end of the interaction. Harder to think about if they’re moving the content, so just the initial drag.
… Scrolls are not necessarily blocked on any event, so they’re a little more complicated. At least on Chrome, you need to have non-passive listeners to block scrolling on events.
… Measure the initial scroll latency, not the event listeners triggered by the user-gesture that caused the scroll
… Need to associate events to interactions (keydown-keyup). Need to allow developers to do this if possible.
… interactionID so keydown/keyup would have a shared ID
… The other problem is there is no way to measure scroll performance. Can measure with event handlers but that will introduce latency.
… The idea is that scrolling is not blocked on event handlers, so impossible to measure this accurately now
… One use case is that developers can force scrolling to happen in the slow path, and when that happens, they should be made aware of it, and that’s likely to be slower
… Need a way to measure initial scroll interaction (scroll begin -- latency between touch move that triggers scroll to the time when the browser first reacts to that scroll - paint)
There can also be use cases for subsequent scroll reactions - for long scrolls operations, subsequent ones are called scroll updates. My initial reaction is that yhey would be better addressed by the Frame Timing API, as they represent frame latency.
… Two ideas how we could expose this
… One - Extend PerformanceEventTiming with new entry, even if it doesn’t have an associated event like the other entries do, name=”scrollBegin”
… Two - a new PerformanceScrollTiming entry, since some of the PerformanceEventTiming attributes are not meaningful for this (processingEnd, etc)
… Happy to hear folks’ ideas on that front
… Evaluating end-to-end latency of an interaction
… Starts with input event timestamp from user hardware
… Then there may be some blocking tasks already in queue to run
… Next is processing time of event handlers
… A frame may be presented on the screen
… After is work kicked off by event handlers (async)
… The final frame is presented on the screen
… For the current EventTiming, we measure the first yellow star (.duration value)
… Async work is hard to track
… We can improve over FID by looking at next frame presented on screen
… In future we’d like to explore looking at what those red tasks should be
… But ATM mostly thinking of exposing the first yellow start (first frame presented on screen), which is currently exposed in Event Timing with duration.
Noam H: Comment on scroll - main idea makes sense because it fits nicely with existing frameworks that use event name for tracking EventTiming. OK that it doesn’t map to a specific dom event.
… On the other hand it’d be fine to have more elaborate Scroll Timing information
Yoav: Do we see if there are cases where we’d have Scroll specific data? Would the data diverge from Events, and have Scroll/Event specific attributes? If so, would be better to start with separate entries.
Noam H: If they diverge we could keep both entries
Yoav: We could, but having that as a duplicate won’t be ideal.
Nicolás: May make sense to separate the entries.
… Question is what scroll updates would require, and that is harder to reason about as a single PerformanceEventTiming entry.
… We don’t want to expose all scroll updates, so we want some way to aggregate them. It’s not clear how, but they may require different values than EventTiming
Noam H: Updates are more about smoothness and not responsiveness to an interaction
Nicolás: Right. If we needed to have Scroll Update here then we should have a new entry. If we wanted to have part of it in FrameTiming, then it could be OK to have the same entry for both. Not sure.
Noam H: Would frame timing include attribution to events
Nicolás: I don’t think so.
Sean: My understanding scrollBegin is the purple area in the diagram you have showing
Nicolás: It should be the same “next frame presented”
… For scrollBegin the diagram doesn’t make as much sense as if it doesn’t happen in the JS thread, then there shouldn’t be handlers (green area).
… On mobile, next frame after the touch move that triggered the scroll
Sean: The two possible scenarios are whether the JS thread/handlers would be involved?
Nicolás: Correct, in some cases the handlers block scrolling and in that case you need the green part
Sean: The diagram is bi-modal in that case
Nicolás: We could expose processingStart/End if it’s blocking scrolling
… If it’s not blocked, they’d both be 0
… That way developers would know it’s being blocked by handlers
Peter: Thanks for the presentation, quick question - working with real world cases after Web Vitals goes live.
… The point where we say work kicked off by event handlers, what I see in some websites is people skip Web Vitals from SEO, by defining loading of third-party snippets until after the user has just scrolled.
Nicolás: If it’s on the scroll event, it would probably not even be captured by the diagram -- async work out of scope of this
Annie: If you’re tracking all inputs, and the first input kicks off some work, that work should be captured by the later input events.