How should Container Timing attributes work? Could multiple observers have different views?

[mmocny]

The current proposal for container timing expands on element timing:

• You apply a containertiming attribute to a node, giving it an id
• You can also optionally apply settings to a sub-tree: ignore, transparent, shadowed.

But this sort of creates a single global perspective that all observers of the page timings must agree to.

For example, if a parent node opts to observe child timings, but then any child also opts to observe its own timings, right now the default proposal is to hide these timings from the parent container. This might be surprising if the two attributes aren't explicitly assigned by the same author.

(I think its potentially even worse with the ignore setting where this is decided globally).

---

There might also be differences of opinion of how to even construct the container timing "tree".

For example, a hypothetical future LCP algorithm might want to apply some default container timing setting for specific nodes (tables, svg, etc), but ignore all others.
This might differ than shape of the tree from an explicit opt-in from a site owner. And that might differ further from the default settings of a "custom component library" that measures timings for its components. Etc.

---

Proposal: could it be possible to establish the shape of the container tree, and settings (like transparent, shadowed, ignore) to specific observers of element timing, rather than applied directly to the dom nodes?

Another potential advantage of this might be: you can publish a dom with data-* attributes which help define container relationships, but this wouldn't actually do anything until an Observer is registered.

[jdapena]

The main problem with not having the attributes in DOM is the fact that we collect the paint data (for buffered mode) before. So it is important to have the container timing tree information beforehand.

A solution I can think of is giving information in the DOM that defines different container timing trees, with its own propagation rules.

One way to do that could be that the containertiming attribute value would be, instead of an ID, a more complex format that would provide more information. Something similar to style:

<div containertiming='tree_a { id: "a_root"; nesting: "transparent" } tree_b { id: "b_root" }'>

Another possibility, using a JSON:

<div containertiming='{ tree_a: { id: "a_root", nesting: "transparent" }, tree_b: { id: "b_root" }}'>

This is an example. It would not be the first attribute with complex contents (we have style, media, rel, etc). The advantage of this approach, on top of having multiple trees, is that it would be more easily extensible in the future without adding more and more DOM attributes.

About the implementation, we would still use the Node flag for checking and emitting the container timing attributes. But, when a node is interesting, it would need to report to all the container timing roots on top. We would need to modify the records algorithm to include this traversal. Once we have this, we would have container timing roots storing more than one configuration, depending on the trees it belongs to. And we could have internal trees that are not even exposed to the container timing observers.

[jdapena]

Oh, and another thing: adding a more complex attribute for timing could allow supporting more than one timing event, or even merging element timing and container timing in the same entry.

I.e. this:

{ scope_a: { id: "a", nesting: "none" }}

I use scope in this case, as in this case it would not always be about a tree, just about which scope this entry would report.

Could actually be another notation for elementtiming. We could move to a new attribute timing that would provide all the information about the timing events a specific element is providing. And deprecate elementtiming and containertiming*.

Consider these last comments a bit of throwing different ideas for this discussion. Definitely multiple view support (specially allowing internal views that do not affect the PerformanceObservers) seems really interesting.

[mmocny]

Good point about attributes being useful to assign values before first parse, so that we have them before first paint, and that this is especially useful for buffering entries.

One desire I've always had for Element Timing API, which might also apply to Container Timing, is that we should somehow support adding the attribute late, even after they paint, and still get an entry back.

In Chromium we might not necessarilky keep the paint timing details for all elements around forever. However, we know if the element was already painted or not, and for images, we can check if the media is already loaded or not, so we can always know if an element should report timing or should wait for a future paint.

I think this means a slightly different interface could be available-- something more like await element.painted() for Element Timing API.

Container timing is harder, because it isn't a single value that can be wrapped in a promise, but rather a stream of events. It could perhaps become a new PerformanceObserver option (.observe({ type: 'container', element: ... })) or perhaps the new Observable interface could be exposed element.containerTimings().forEach(...).

With such an interface, its not "the shared dom" that dictates containers, but rather each observer does. Depending on the use case this may or may not be better.

[jasonwilliams]

But this sort of creates a single global perspective that all observers of the page timings must agree to.

For example, if a parent node opts to observe child timings, but then any child also opts to observe its own timings, right now the default proposal is to hide these timings from the parent container. This might be surprising if the two attributes aren't explicitly assigned by the same author.

So I guess this was meant to be analogous to something like Shadow DOM, whereby a container can decide to close off its implementation detail (in this case, internal paint events) from emitting outside of it’s boundary (regardless of whether a parent is interested or not).

This might be surprising if the two attributes aren't explicitly assigned by the same author.

I think you’re right it can be surprising, it was set this way because a container by default was self-contained and didn’t leak out any detail unless explicitly opened (which is more likely when done by the same author).

I appreciate it does become more inaccurate the more you do this though as the outer container is discounting more and more content so giving false numbers. An example is a component wrapping ads which may need to be timed, the overall header (by a different author) only wants to time its own content.

One desire I've always had for Element Timing API, which might also apply to Container Timing, is that we should somehow support adding the attribute late, even after they paint, and still get an entry back

Yeah we had issues with this in the implementation because right now we only store data on nodes we know are [in] containers as they’re painted. If we don’t know ahead of time we need to store data for every paint and it could cause a performance overhead.

We also wouldn’t know how long to hold that data for either as we don’t know when an observer will start observing (do you have a timeout or indefinitely keep paint data which wont be used).

One way to circumvent this would be to have some selector in the head which tells the browser ahead of time which selectors were interested in, but I don’t think there’s much prior art to that apart from CSS.

The other option is to see if we can store such data in an efficient manner so it can be served later and not have much overhead.

It could perhaps become a new PerformanceObserver option (.observe({ type: 'container', element: ... })) or perhaps the new Observable interface could be exposed element.containerTimings().forEach(...).

From a users perspective I would have said the Performance Observer makes sense to me, we already have takeRecords() and a buffer to represent entries not consumed yet. However from an implementation perspective, the observer doesn’t exist yet, I think this is already handled by having a “global” buffer for entries (currently limited to 150)

[jasonwilliams]

In Chromium we might not necessarilky keep the paint timing details for all elements around forever. However, we know if the element was already painted or not, and for images, we can check if the media is already loaded or not, so we can always know if an element should report timing or should wait for a future paint.

Right, but entries (which hold timestamps of when those paints happened) are only created and held for interesting elements. So even if we know when an image or text painted, we don't have the paint times.

I don't see how else this could be done without having some sort of manifest which is loaded early before the main body.

<head>
...
  <script containertiming type="application/json">
    {
      "containers": [
        {
          "selector": "#main-widget",
          "identifier": "mainWidget",
          "mode": "transparent"
        },
        {
          "selector": ".card",
          "identifier": "cards",
          "mode": "ignore"
        }
      ],
      "elements": [
        {
          "selector": "img.hero",
          "identifier": "heroImage"
        }
      ]
    }
    </script>
</head>

We may not need the "elements" section if we're subseeding that with container timing

This would solve the "buffered" scenario of the browser knowing which elements to retain paint information without blowing up memory saving paint information for every element.

One desire I've always had for Element Timing API, which might also apply to Container Timing, is that we should somehow support adding the attribute late, even after they paint, and still get an entry back

Yeah the list above looks quite static at the moment, so it would also need to be accessed via the Performance API so it can be updated on the fly, i.e you can add a new container to the "containers" list.

[mmocny]

only created and held for interesting elements

True-- but ultimately, those timings come from a common set of paint timing records. We have historically tried to constrain the paint timing detectors to only bother recording "interesting elements", but that set is approaching 100% for various reasons, and I think is likely to switch to 100%.

The elementtiming attribute is currently still used to ensure opt-in here, but I think it won't be needed for that, eventually.

(Note: we are working to cleaning up and unifying these records and detectors -- between media types and between consumers like LCP and element timing -- so today some of the element timing specifics are different than for LCP, especially for images).

---

That's just the recording side of things. After that is completed, Chromium does currently choose to discard the full paint timing records once consumers have a chance to observe them. Each consumer has to choose to hold on to records beyond that.

For this, the elementtiming attribute is currently necessary as both the mechanism to opt-in to observe these elements, but more importantly, to ask to buffer these values. (A manifest, or an eagerly registered PerformanceObserver-- assuming it had an element list-- could be alternatives).

---

However, while we might discard full paint timing records, we do always keep a permanent list of all nodes we did collect for (i.e. we can know if they were painted, even if we don't recall the specific timing).

Thus, even without this pre-emptive buffering, perhaps you can still lazily ask for the element timing of an element that was already painted, and at least get a confirmation that the element was painted (without having specific timing values). Today this is already an issue for late-added elementtiming attribute.

---

Beyond that, although we haven't finished evaluating feasibility, we suspect it might be possible to keep paint timing records around for longer than we currently do.

[jasonwilliams]

I've put together a doc detailing the options for how we declare containers here:
https://github.com/bloomberg/container-timing/blob/main/docs/container-definitions.md

Please take a read and come back here with any ideas or discussions