The group where the incubation/design work on this is being done (or is intended to be done in the future): This will likely move to WICG or the Web Perf WG.
The group where standardization of this work is intended to be done ("unknown" if not known): This will likely move to WICG or the Web Perf WG.
Existing major pieces of multi-implementer review or discussion of this design:
Major unresolved issues with or opposition to this design:
This work is being funded by: Bloomberg
You should also know that... y'all are great, keep up the great work!
Yoav: this is an extension of element timing to cover entire containers rather than specific elements... element timing covers only images and paragraph. This is a community driven effort to improve on that.
... discussed in the webperf working group... will probably be folded into the element timing spec which is in that wg. Driven by Bloomberg and Igalia.
Dan: have we done a review on element timing.
Yoav: it shipped in Chromium in 2019...
Dan: any privacy / security?
Yoav: large parts of this are polyfillable with element timing... it did have a polyfill at an earlier stage... Nothing seems particularly novel. Would need to collect all the element timings from all the elements inside the container... At the same time it would be worth while to ask that question on the issue...
Thanks for bringing this our way. Regarding privacy, security - you've noted that "this is essentially an extension of the Element Timing API". That's understood. Since that was reviewed in 2018, have there been any additional issues raised with element timing API regarding privacy or security that might inform the design of this extension?
Comment by @jasonwilliams Apr 1, 2025 (See Github)
Hi @torgo, thanks for taking a look at this.
have there been any additional issues raised with element timing API regarding privacy or security that might inform the design of this extension?
Yes, there is the PaintTimingMixin which was added to PerformanceElementTiming last year and also exposed to largest-contentful-paint. This does expose some extra information around paint timing to both and its unsure at this time whether Container Timing would need these extra properties right now. There have been several learnings were recently applied to element timing around security, and container timing should be following all of them.
Secondly, Container Timing doesn't expose any new information on top of element timing, it just aggregates the same information for a container. All of the properties listed here can be achieved by using element timing on all elements within the same area.
@mmocny and @jdapena should have more information if needed
PerformanceContainerTiming entries should support the PaintTimingMixin. Internally we are already storing it, and that would be exposed the same way. Main thing is that we need to also provide a way to get the paint and presentation times for the first paint.
Right now PerformanceContainerTiming.startTime is the last presentation time and lastPaintedElement is an element that was presented at that time. We need to decice if we want to have lastPresentedElement and lastPaintedElement. And we need to specify that startTime is the last presentation time explicitely.
About firstRenderTime, maybe it should also be firstPresentationTime and firstPaintTime, and drop firstRenderTime. This way we will be able to get a complete view of presentation and painting.
Now, about the security/privacy: we need to incorporate the coarsening algorithm in the specification. I also need to review the native implementation (we are already using as input the coarsened numbers used for ElementTiming, so we should be already fine).
Hadley: it looks like this is for developer needs, and site author needs. Not so much user needs.
Lola: right, but does it still improve the experience for users in some way?
Hadley: Ideally, I would love to see that in their explainer. We can speculate, but it would be nice for them to think about things that way.
Lola: no harm in saying that
Hadley: It feels like this could add to the fingerprinting surface area. Gives info about the rendering times for that user.
Lola: is that info unique?
Hadley: that's why we talk about fingerprinting surface area. The more we can slim it down, the greater the chances are that it's not unique.
I know Dan asked about security and privacy, and I suspect that's why. Let's look at that.
We have a design principle on not making it easier to do bad things, just because they're already possible now. We could mention that. (I think it's leave the web better than you find it).
Lola: but Jason says, "Container Timing doesn't expose any new information on top of element timing, it just aggregates the same information for a container." Is that making it easier to do bad things?
Hadley: maybe? If it is the design principle is applicable.
[we review]
Hadley: I'd like to know if this add to the fingerprinting surface-area and for someone who's more javascripty than me & torgo to take a look at it. I can draft a comment. hadley posts comment asking clarifying questions
Comment by @hadleybeeman Apr 10, 2025 (See Github)
Hi all. We are looking at this in our TAG breakout. Two quick questions (and then likely more to follow):
Do you think this adds to the fingerprinting surface area for a user (or UA context)?
How do you expect the coarsening algorithm to work here? Can you spell that out for us?
Hi all. We are looking at this in our TAG breakout. Two quick questions (and then likely more to follow):
Do you think this adds to the fingerprinting surface area for a user (or UA context)?
As this can be polyfilled on top of Element Timing, it does not really add any new fingerprinting surface. Same considerations should be made for intersection rect and timers. The native implementations should be using coarsened timers as in ElementTiming.
How do you expect the coarsening algorithm to work here? Can you spell that out for us?
Torgo: They responded to our message from 2 weeks ago. They've spelled things out in the Security & Privacy Considerations. We ought to wrap this up. Don't think there's much controversy here. We do generally double-check when people say "we're not "
Yves: The fact that it's polyfillable is a good reason to allow it to ship. Avoid extra JS libraries.
Torgo: Close with satisfied, and I'll write the closing comment.
Jeffrey: Seems fine to close it with the breakout.
Hadley: Christian had some good things to say about this. He has some deep knowledge of it. I don't know a ton about this; asked them to spell out the coarsening algorithm they wanted to use to increase privacy. Looked at this a while ago and I don't think the info they added answers the qeustion. They're saying, in the element timing spec, implementations are advised to coarsen to at least 4ms to avoid cross origin issues. So that sounds reasonable.
DanA: Agree. Did Christian have concerns?
Hadley: IIRC Christian knows a lot about the history and what they're trying to accomplish.
DanA: I remember that too. Does it mean we should hold up? Do we feel there's nothing more to do here?
Jeffrey: Minutes say we should close as satisfied after writing the comment.
Yves: That it's polyfillable is a reason for it to be OK.
DanA: I'll write the comment right now.
Hadley: There's a comment in the thread that explains that it doesn't add any fingerprinting surface as it can be polyfilled.
OpenedJan 7, 2025
こんにちは TAG-さん!
I'm requesting an early TAG design review of the Container Timing API.
The Container Timing API enables monitoring when annotated sections of the DOM are displayed on screen and have finished their initial paint.
Further details:
You should also know that... y'all are great, keep up the great work!