Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

When to stop observing? #13

Open
jasonwilliams opened this issue Jan 31, 2025 · 0 comments
Open

When to stop observing? #13

jasonwilliams opened this issue Jan 31, 2025 · 0 comments

Comments

@jasonwilliams
Copy link
Member

jasonwilliams commented Jan 31, 2025

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant