You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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
The text was updated successfully, but these errors were encountered:
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 top 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=chromiumAs 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
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
The text was updated successfully, but these errors were encountered: