Clarify the `lastPaintedElement` semantics, and consider using "largest element (in this paint update)"

[mmocny]

I see that there are notes in the README that this attribute may need to evolve into a list:

"this may need to be a set of elements painted"

(But I somehow doubt that this API will evolve to actually report the FULL list of all elements.)

The current specification implies that this value would be the literal last element that updates area, even by 1px, based on implementation defined paint order. (see https://wicg.github.io/container-timing/#maybe-update-last-new-painted-area and https://wicg.github.io/container-timing/#ref-for-maybe-update-the-last-new-painted-area).

We recently worked on changes to the LCP spec to try to remove paint implementation order differences w.r.t. LCP candidate reporting. We resolved this by taking two passes:

• First, taking ALL element paints in one rendering update, and find the largest overall for that paint
• Then, compare that element against the previous largest candidate from all previous paints to see if we have a new largest.

This way, the relative element paint order doesn't matter for candidate selection.

---

I wonder if a model like this could be borrowed for Container Timing?

I think you already observe the same stream of paints at the same moment and order as LCP. After filtering down to elements which are part of a container tree, you could iterate the elements from largest to smallest element, and find the largest element that actually does update the size of the region.

Alternatively, you could keep a copy of the previously recorded region while you are updating the new region, and consider any element that would update the old region by even 1px to be a viable candidate -- not just those elements which update the current region.

(FWIW, Container Timing right now just has a "When an element is painted" hook which is per-element, but this isn't the right integration with paint timing nor element timing, I think)

See:

• https://www.w3.org/TR/largest-contentful-paint/#sec-report-largest-contentful-paint
• https://w3c.github.io/element-timing/#sec-report-element-timing
• https://www.w3.org/TR/paint-timing/#mark-paint-timing (Step 10.3 and 10.4)

[mmocny]

A second oddity of the current behaviour, I think, is that container timing paints are only reported when overall size actually increases.

At face value, this makes sense, but for stacked content updates it means that the stream of paints is dependant on the size overlap between them.

Take this example:

• A stock ticker starts at 99.9$, fires an CT entry.
• Updates to 100.0$, fires an CT entry.
• User reloads the page
• A stock ticker starts at 100.0$, fires an CT entry.
• Updates to 99.9$, does NOT fire a CT entry.

Thus, the page loads slower only when the stock goes up.

---

There is NOTE about this in the spec:

Note: This algorithm reports any change to the painted region, regardless of size. Even a 1 pixel change in the painted area will result in a new PerformanceContainerTiming entry being queued. Developers who wish to filter out small changes may do so by comparing the size values between entries.

This makes sense. But what if I wanted to do reverse? What if I wanted to observe the second update paubnt, even when it has a 1px smaller size than the previous region?

---

An alternative mechanism for Container Timing would merely report all paints, whenever those paints have any new contentful element paints within the container. The container size overall may not change with every update, but each update would have its own lastPaintedElement which could be the largest for that paint.

This would solve two problems:

• Give developers more ability and options for observing a stream of contentful paints within their containers (potentially all the way to to "Fully visually complete").
• Enable a mechanism for reporting new elements that are very large but within previous parts of the container region.

[jdapena]

I like the idea of LCP. And it may not be hard to implement. Right now we store the lastPaintedElement, that is easy to maintain as we just update the value when a new paint is increasing the damaged area.

Possible alternates

Alternative 1

Cheap, but less consistent.

We set lastLargestPaintArea to 0 when we emit a container timing entry.

Then, as we get new paints:

• First we see if the new paint increases the region.
• If the region is increased, we compare the painted area with lastLargestPaintArea. If it is bigger than previous value, then we store lastPaintedElement (or rename as lastLargestPaintedElement).

Then when next container timing entry is generated we use the lastLargestPaintElement

Problem: as we increase the area, a largest paint that is not increasing the area (but could have been detected as increasing if processed before) would not be showing. As we emit the entry for each frame, it should not be a big deal.

Alternative 2

We could maintain a lastEmittedRegion, that would be the region emitted in the last container timing entry.

Then, for all paints, we see if they increase the painted region compared to the lastEmittedRegion, and in that case we compare with the lastLargestPaintArea.

Relation to other changes

Continuous tracking

Both ideas would work properly for a new continuous container timing tracking event (container-paints?) that would just emit always even if it does not increase the region. They would just, for each paint affecting a container timing, reflect the total painted area, the intersection rect of it, and the largest painted element.

Exposing the region

If we want to expose accurate information about the parts of the screen that were actually damaged, we could expose the regions. This would apply both for continous tracking and current container timing. We would have the data ready and we would just need to provide a way to extract that from the container timing entry. The overhead would happen only on accessing the attribute.

[mmocny]

Related: consider adding a sizeDelta attribute to the container timing, so you could report paints for a 0 delta and it would still be clear.

---

This also reminds me of CLS, which accumulates score of shifts over time. Most libraries that implement this accumulation will report a running total CLS score, as well as attribution about the most recent shifts, and a delta value from last update. But not all reports increase the score.

[jasonwilliams]

Just to update this thread, we've since discussed offline that instead of a lastPaintedElement attribute on each paint iteration, we have a mostImportantElement instead. This will be the largest element in each paint iteration (the LCP of that paint).

lastPaintedElement was never really accurate as there are scenarios where it may not always be the last, plus there are many elements that paint at the same time and we just choose the last one in the stream (but it's only last by some undefined order the browser gives). Having the largest makes more sense.

Related: consider adding a sizeDelta attribute to the container timing, so you could report paints for a 0 delta and it would still be clear.

Yeah I like this idea, we've been doing this in userland on top of the API anyway to get an idea which paint update is significant or not

[mmocny]

RE naming mostImportantElement vs lastPaintedElement, I think the goal of these is to report on the element within the single most recent paint, is that right?

It would be useful I think to have a long-running "most important element" as well-- but I suspect this should just be the overall largestContentfulPaint element (which is what the interaction-contentful-paint entry does).

In that case, I think this other value maybe can continue to be named the lastPaintedElement and just change the spec semantics to be ensure it is the largest in that recent paint?

[jdapena]

Using LCP idl in ContainerTiming event seems a big improvement. And being able to report the total LCP so far would also be great.

I think it would be good to avoid reusing existing members, unless the existing name is so good there is no better option, and I don't think that's really the case.

What about this?

interface PerformanceContainerTiming {
  ...
  readonly attribute Element? lastPaintedElement;  // deprecated
  readonly attribute DOMHighResTimeStamp firstRenderTime; // deprecated
  readonly attribute LargestContentfulPaint largestContentfulPaint; // largest so far
  readonly attribute LargestContentfulPaint lcpSinceLastFrame;  // largest in this frame
  readonly attribute PaintTiming firstPaint;  // replacing firstRenderTime
}

What we would need to store that would be new?

• first paint presentation and paint time instead of a single render time value.
• largestContentfulPaint completely (presentation and paint times, size, id, url, element).
• lastLargestContentfulPaint (size, id, url). Element would be selected to be the largest contentful paint.

Some doubts about this:

• I guess we could even decide to deprecate PerformanceContainerTiming implementing the mixin? Though, I don't think we need that. We can make PerformanceContainerTiming paint mixin return the same as the lcpSinceLastFrame paint mixin.
• The naming for lcpSinceLastFrame... I don't like it. Feel free to propose the ideas.
• The deprecated flags would be removed eventually (i.e. after the current origin trial).

We would need to store more information in the ContainerTiming object, but I don't think this would be really insane, and would make it easier to respond to the general idea of "what was the time of the largest contentful paint for this container, so far?".

[mmocny]

What about this?

I'll compare to InteractionContentfulPaint, which "models" a type of container timing:

• The largestContentfulPaint attribute matches the latest implementaton and spec.
• I like the idea of exposing a lcpSinceLastFrame though I think the name could be tweaked (as do you).
  • I thought that lastPaintedElement was a good name, and could just be replaced with an ElementTiming entry rather than single Element reference
  • Perhaps: lastContentfulPaint or latestContenfulPaint or something?
• For "first paint", ICP doesn't current expose a specific attribute and instead just make the first reported entry the first paint value.

I guess we could even decide to deprecate PerformanceContainerTiming implementing the mixin?

It is true that when you expose a nested LCP/element timing that the paint timing info is somewhat redundant. However, you likely want a startTime and/or duration on the entry that matches the presentation time-- so I think its not a problem to just expose all the attributes for consistency.

We would need to store more information in the ContainerTiming object

Under the hood you will already store these same things, because the timings are in terms of the individual element paints. This feels like the real complexity/hard parts. Upon emitting a new entry you will expose a few new static values which seems fine.

[jasonwilliams]

I've created a PR which addresses the new semantics of lastPaintedElement whilst keeping the field the same, please let me know your thoughts and if its good to go: #61

[jdapena]

I like the proposal yes. Though I will propose having the new model of embedding an LCP entry, this would be an intermediate step to unifying how things work with ICP.

[jdapena]

After discussion yesterday, some ideas to cover this:

• We could try to move away the concepts of reporting first paint and LCP so far from the PerformanceContainerTiming entry.
• We could add an API to query, for a container timing root, its first paint and its LCP so far. Something like performance.getContainerTimings(Element) that would return something like { firstPaint : PaintTiming, largestContentfulPaint : LargestContentfulPaint}.
• PerformanceContainerTiming would have its field largestContentfulPaint : LargestContentfulPaint for reporting the LCP since the last entry. This would replace lastPaintedElement. firstRenderTime would be removed also as it would be possible to query it from getContainerTimings.

(A new idea today). We could also have performance.getContainerTimingInfo(Element) instead of performance.getContainerTimings that would return more information:

• size would report the accumulated size so far.
• firstPaint : PaintTiming and largestContentfulPaint: LargestContentfulPaint as explained before.
• identifier: the CT element identifier.
• intersectionRect: the enclosing rectangle in viewport.
• rootElement: the same element.

We could even have a method in PerformanceContainerTiming entries to retrieve the container timing accumulated info directly, so we can process it from the observer or whenever we have access to the entry.