When to stop observing?

Observing containers can be costly, so we should discuss if there needs to be normal "cut off" where observations stop. This would prevent the performanceObserver running during the lifetime of the page/application.

For LargestContenfulPaint we stop observing on interaction. You can see this is implemented in Chromium here: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/paint/timing/paint_timing_detector.cc;l=264-288?q=paint_timing_detector&ss=chromium

As container-timing is currently seen as "page load" metric, it could follow LCP by unobserving on interaction.

What does elementtiming do?

As container-timing is seen as a superset of element-timing and reusing some internal components another argument would be to follow elementtiming. elementtiming does not stop observing, even on interaction. Some users take advantage of this fact and use it for purposes other than "page load", we probably want to identify what people will be using container timing for to know where observing should stop.

For example:
https://issues.chromium.org/issues/377830100

We likely should enforce that element timings only fire when the content is actually viewport intersected, however, the whole idea of reporting an element timing after a user scroll is potentially confusing.

I'm indifferent to when the timing actually fires, but I do feel the idea of reporting an element timing after scroll doesn't make much sense. The time will still be measured from timeOrigin which will now include scroll time and won't be very useful at all. If people want interactions to paint then INP would make more sense and maybe container timing should integrate with that metric instead.

Measuring container paint since last interaction

You could do this today with both the Container Timing API and the Event Timing API but it would be tricky. The duration from the Event Timing entry would show the delta between interaction and the next paint, but it may not necessarily be the paint for the container. You would currently need to wrap both observers in something which reconsiles the data together.

To make this easier we could add interactionIds to Container Timing events, to allow developers to join up the 2 events better. these IDs would be 0 for paints on page load, but populated with a number for paints triggered from interaction. You would still need to match the IDs from these entries with the IDs from Event Timing entries to get a duration of interaction to container paint time.

You could observe "events" then

Start by reading the Chromium paint_timing_detector.cc section linked in the issue, then compare the stopping behavior of Largest Contentful Paint and element timing. Review the proposed Event Timing interactionIds approach; done means reaching and documenting a decision about when container-timing observation should stop and whether interaction IDs are needed.