Participants
Nic Jansma, Yoav Weiss, Annie Sullivan, Pat Meenan, Sean Feng, Noam Rosenthal, Markus Stange, Jacob Gros, Guohui Deng, Jase Williams, Amiya Gupta, Michal Mocny, Rick Klein, Jeff Muizelaar, Bas Schouten, Barry Pollard, Philip Tellis, Mike Henniger, Jose Dapena Paz, Bas Schouten
Admin
- Next call - November 21st
- Unconference next week ahead of perf.now() in AMS
- Free signup: https://docs.google.com/forms/d/e/1FAIpQLSdqlG8lh3Bl-5o8qLuLMfFmMp6ciGps70T9d1APFx-HIiRONg/viewform
- https://wiki.mozilla.org/Performance/FOSDEM_2025_Call_for_Participation
- Autotranscribing bot - W3C requires manual scribing, so no bot
Minutes
PaintTiming #62: Timestamps should be specified in an interoperative way
- NoamR: Was on the agenda a few times. We’ve consolidated this to a proposal
- .. expose paint/render time in various places
- .. eventTiming has a duration that ends at a paint
- … LoAF ends at something, LCP and Element Timing have renderTime
- …
- … “handover” and “presentation”
- … handover - when the main thread delivers layout
- … after that a lot of fancy things happen internally in the browser
- … and present happens after that
- … In LoAF, the duration is handover time
- … For everything else, we don’t have interop. They are handover in non-Chromium and presentation in Chromium
- … We can’t really define the “present” time as it depends on implementation-defined internals
- … wondering if this is OK
- … Two of those already - rAF is somewhat implementation defined
- … Similarly for UI events, the timestamp is implementation and hardware defined
- … at the same time, it makes it hard to compare browsers
- … but they are important UX-wise. Users can use them to spot regressions and browsers can use them to benchmark themselves
- … So we can have a non-interop timestamp in the spec, or not specify it at all (don’t like it)
- … We can also call it UASpecificSomethingSomething, to set expectations
- … Proposing to have those two timestamps in all those different entries, and call them paintTime and presentationTime, in LCP, ElementTiming, EventTiming, etc
- … Current startTime/renderTime would go to one or the other
- … Let’s discuss
- Michal: Can Mozilla folks confirm the statements RE the timestamps?
- .. end time of event timing for “duration” and LCP, is it marking the handover or the presentation time?
- Bas: I believe it’s correct, but not 100% sure
- Michal: Would you be comfortable exposing both timings?
- Bas: I’m inclined to say yes. Maybe there are security and privacy concerns?
- Markus: We already expose how long we take for compositing, so this won’t make it worse
- Noam: We also plan to make those timestamps very coarse (4ms), so you can use variation to find the decoding time of cross origin images
- Jeff: Can’t you run it a lot of times?
- Noam: It makes it less useful
- Jeff: It’s still tighter than the 16ms you get from rAF
- Michal: The timing of the presentation is a global property. So any mechanism to measure that should be significantly coarsened, other than pages that are crossOriginIsolated
- … So we make sure that the info doesn’t leak anything
- Markus: so what we have is not the handover time but something earlier than that
- .. Gecko exposes the timestamp before we call rAF callback. (the dot all the way to the left in the diagram)
- Jeff: Don’t we do that because that’s what the spec says?
- NoamR: “update the rendering” includes rAF callbacks.
- Michal: There are multiple timings. The before timestamp is passed to rAF, but e.g. resizeObserver fires afterwards. So it’s already web observable
- Markus: So sounds like the timestamp is now unnecessarily early
- Bas: We can fix that
- … Other question is “renderTime” can it be the presentation time?
- … If it’s coarse, there’s no problem with it
- … rAF is bound by vsync, if you have a high fps screen, that’s already fairly high res
- … so it doesn’t feel like a coarse presentation time timestamp would add unexposed data
- Michal: There’s some complexity with rAF due to pipelining, and scheduling
- … You can request a raf callback but there are reasons why it not be scheduled
- … So there’s a slight difference but it could be web measurable
- Bas: And you can construct a situation where it’s observable
- Markus: It could add more observability
- Michal: We already expose `decode` as an API
- Noam: But it’s not guaranteed to give you the right timestamp. It could be very coarsened, resolve the promise later, etc
- Markus: For completeness, rAF is pipelines. So raf may not be delayed, but raf+2 would be
- … all this to say that I think it’d be fine to put these timestamps as presentation time
- … Current proposal says it’s not guaranteed to be there, so we could remove it worst case
- Michal: All these entries have startTime + duration, so there’s already a fallback to the largest time
- … This would also make it explicit about what’s measured making it easier to compare
- … i.e. paintTime vs renderTime vs loadTime
- … just expose consistently and coarsen consistently, so we’d have element timing with the most exposed timestamp
- Bas: how much, because of how webrender works, can people use iframes to try and deduce information about the content of iframes?
- Markus: let’s discuss offline
- Yoav: No one is asking for security commitment on the spot, just to reach conclusion on what we want to do, and each team can speak with respective security folks
- Bas: My inclination for “want” is “yes”
- … Understanding historically that Apple’s objective here is they don’t have that time?
- Noam: I don’t believe any Apple employees are on the call
- … FCP in WebKit, one is that the value is very deep within Coronation(?)
- … Other is that they didn’t want to create things that can’t be compared between browsers, sensitive to comparison across
- Bas: But we’re trying to make them more comparable
- Noam: This can’t be exactly comparable because there’s some hand-waving in algo
- Michal: If they don’t expose presentation time, if we make it obvious what paintTime is in other browsers, then those timings are more comparable
- Noam: In WebKit rAF start is not vsync-aligned
- … taskStart of the rAF
- Marcus: I’m not sure if it’s the same in all cases in Gecko either
- Bas: Agreement between Google and Mozilla
- Yoav: Given proposal is to make presentation time optional, that’s less likely to hit resistance
- Michal: All of this is the status-quo, just making it clear, more consistent, and probably in the end safer
- Marcus: I didn’t see in Github issue which types of events this would apply to and their property names
- Noam: I can do that
- Marcus: I found this presentation very helpful thank you
- Yoav: In terms of backward compatibility, we’re not planning on changing semantics of current entries?
- Marcus: Semantics of startTime would change in Gecko to align with Chrome
- Yoav: Would be good to examine those on a case-by-case basis
- … Recent experience with changing responseStart and firstInterimResponseStart and changing of semantics that left us with Interop issues
- … Make sure to think through these as well
- Michal: One difference in Chromium is startTime uses either renderTIme or loadTime
- … renderTime is only available if we can expose real presentation time
- … paintTime would always be available
- … So the startTime for ElementTimings will more often represent the real time
- Bas: startTime would never represent loadTime anymore, as paintTime would always be available?
- Michal: Correct, and there’s already coarsening happening
- Marcus: Can page tell if presentation Time is available
- Noam: Yes, zero’d out
- Marcus: Example in Chrome?
- Bas: For cross-origin images?
- Yoav: Used to be the case, recently changed with coarsening because it can be measured by other means so the restriction won’t apply
- Michal: Hasn’t shipped yet, making it’s way through: more coarsened, but always available
- Yoav: Also a change we’ll have to think through backward-compat implication
- Bas: If it’s always available in Chrome, last line would only be applicable to other browsers
- Yoav: Only for non-TAO
- Michal: In terms of compat risk, you already have to test for both cases
- … No pages break with this change. RUM data would change
- Yoav: UA-specific and version-specific in back-end
- … Not breakage
- Nic: Chrome’s changelog is great at making these things explicit. Need to explain that intentional change meant to make things more accurate
- Markus: We’d sent an intent to ship and add to the release notes
- Yoav: same in Chromium
- … We have a resolution, let’s make it happen
- … Security review
- … Be open about changes
Resource Timing proposal: API for exposing resource requests (RT 137)
- https://github.com/w3c/resource-timing/issues/137
- Yoav: Proposal for FetchObserver open for 7+ years
- … At the same time, we’ve had an issue/request to be aware of ongoing fetches as part of ResourceTiming
- … Two efforts (stale) can be combined
- … Ideally make some community momentum around those
- … Can enough of us think through proposal, provide feedback, write tests
- … Right now FetchObserver proposal is only for fetch() calls but could be expanded for all page fetches
- … Would like to make this a reality
- Noam: Discussed, general positivity, not enough firepower behind it
- … Someone just needs to do the work
- Yoav: So we should be this “someone”
performance.bind()
- Explainer: https://github.com/w3c/long-animation-frames/blob/main/user-defined-script-entry-point-explainer.md
- Noam: Talked at TPAC on user defined script entry points
- … expose script entry points in LoAF - callback, events, promise resolvers
- … We exposed it to RUM and people complained about it being too coarse
- … attributes things to the wrapper rather than to more useful things
- … `performance.bind` that works as a drop-in replacement for a function bind
- … this defines a user entry point and make it appear in LoAF as if it was an entry point
- … Had an action item to see how this would work with microtasks, as multiple things can be mixed in the microtask queue
- … Seems plausible to separate those timings both in spec and in V8
- … Proposal is to have all those scripts with a “self duration” - time spent in the function and descendants that are not bound
- … Wanted to draw the attention to the explainer
- … We mostly see it useful for LoAF, but could be useful to other things in the future (e.g. devtools)
- … Bikeshedding wise it could be more related to LoAF, but doesn’t have to be
- … Implementation complexity is mostly around microtasks and around how to expose the data
- … Currently entry points are platform defined and we want to make it also user defined
- Jase: Is it only for LoAF or for general use?
- … You touched on it, but I can see it being useful in general to add things to the performance timeline
- Noam: Might be a later extension. Need to not DoS the timeline buffers
- Michal: Proposal to only expose these entry points above X ms (similar to LoAF)
- .. would we want to expose this for any bound function even if it’s fast? Not sure
- … longness shouldn’t be the only criteria
- … similar to event timing, we may add criteria beyond timing
- Noam: Implementing this in user land is basically perf.now() before and after
- … So the feature would be to add it to the timeline only in certain situations
- .. also microtask would be harder
- Bas: There’s some implementation work that would need to be done. But fundamentally, this makes sense and doesn’t seem problematic
- … Not much to complain about 🙂
- Noam: Major complaint about LoAF, so prioritizing it
- Markus: rAF handler function may have multiple callback during the same tick
- … microtask queued while it runs and runs afterwards
- … the microtask would be attributed to the raf callback?
- Noam: Each raf callback is a separate checkpoint
- … but inside the raf callback you want to define your internal functions as entry points
- Markus: So the browser would measure a single call to these functions and when it hits a certain threshold it’d report it?
- Noam: As part of LoAF. It has to contribute to actual jank
- Markus: So for each microtask you’d need to measure those and add those?
- Noam: Implementation wise we’re not measuring each one, just when there’s a context switch.
- Markus: so measure differently if they were queued by different callers
- … and when a microtask queues other ones, you continue to propagate that
- Michal: Does Mozilla have a way to propagate state to microtask?
- Markus: not sure
- Michal: Also used in the scheduling APIs. So a useful feature
- Sean: working on implementing it
- Bas: Are we propagating state or keeping tabs on the queue? The final microtask in the queue needs to know priority
- Sean: tracking origin
- Markus: Doesn’t sound like it’d place undue strain