#1034: Container Timing API

Visit on Github.

Opened Jan 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:

  • I have reviewed the TAG's Web Platform Design Principles
  • 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!

Discussions

Discussed Mar 1, 2025 (See Github)

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...

Dan: previous tag review - we were satisfied.

Jeffrey: sounds right to me....

Yoav: moz have been somewhat supportive but no official position...

Dan: leaves [comment](https://github.com/w3ctag/design-reviews/issues/1034#issuecomment-2766825476 Maybe we can close this at the plenary.

Comment by @torgo Mar 31, 2025 (See Github)

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?

Discussed Apr 1, 2025 (See Github)

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

Discussed Apr 1, 2025 (See Github)

Postponed.

Discussed Apr 1, 2025 (See Github)

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.

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

Comment by @jdapena Apr 4, 2025 (See Github)

About the Mixin:

  • 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).

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):

  1. Do you think this adds to the fingerprinting surface area for a user (or UA context)?
  2. How do you expect the coarsening algorithm to work here? Can you spell that out for us?
Comment by @jdapena Apr 16, 2025 (See Github)

Hi all. We are looking at this in our TAG breakout. Two quick questions (and then likely more to follow):

  1. 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.

  1. How do you expect the coarsening algorithm to work here? Can you spell that out for us?

I think the Element Timing API security and privacy section applies pretty well here: https://w3c.github.io/element-timing/#sec-security

We will need to add a reference to it or repeat most of the Element Timing wording for the Container Timing render time details.