Element Timings and below-the-fold content report arbitrary timings and not useful intersectionRect.

[valiantvu]

If an element is scrolled out of view before it has finished loading, its intersectionRect will be 0. It would be useful to have the intersectionRect be based on the initial viewport (when the element was added to the DOM) instead of the current viewport at render time. This would enable collecting timings for elements that were in the initial viewport based on its intersectionRect. The comparison can still be done after the element has rendered, but the element would be compared against a representation of the initial viewport.

[npm1]

Hi, thanks for the issue! Basing it on the 'initial viewport' might have the problem of us not knowing the real image size at the time (not sure about this). But I can see how it could be useful to base it on the first rect. Which comparison are we talking about here?

Does your website add all images to the DOM at the beginning of page load? If it doesn't then I think this additional intersectionRect might not always provide the information you want. It seems possible for an image to be added to the DOM when the user has scrolled into its coordinates, and the 'first intersectionRect' would be nonempty but it was not part of the initial viewport.

While I give this some more thought, I'll note that an alternative is to use IntersectionObserver to track the elements that are most likely within the initial viewport (I think it can be used to determine if they are indeed in the initial viewport or not).

[valiantvu]

I was thinking the intersectionRect could still be calculated once the image has rendered, at which point we know its size and position. However, instead of comparing against the current viewport we could compare against a representation of the initial viewport. This is essentially what we do at Pinterest - we create a bounding box representing the viewport on initial page load. After this bounding box has been filled, we check to see which images were inside the bounding box so we can record their resource timings (these are part of the custom perf metric we monitor). We server side render the page so all images are added to the DOM at the beginning of page load, but we do check that the viewport is filled before collecting timings in case the user has a large screen that requires client side rendering to completely fill the viewport with images. We have additional metrics for timing elements during subsequent scrolls.

Speaking more generally, it seems like sites would often want to track performance for the initial page load, specifically timings for elements in the initial viewport. It seems like intersectionRect could help with this use case, but if there is a stronger use case for basing intersectionRect on the viewport at time of render I wonder if there might be a way to optionally pass in an element for comparison (e.g. bounding box representing the initial viewport)?

[npm1]

I think generally it's hard to determine the 'initial viewport'. Chrome tries to paint quickly at the beginning of the page load, which means we might not even have fully constructed and parsed the DOM by the first paint. Also, imagine there's some JS code which is loaded asynchronously and adds a bunch of DOM nodes: do these count for the 'initial viewport' or not? Another problem is that user input could change the DOM elements being displayed, so we'd need to be careful about this when deciding when to compute the 'initial viewport'. In general, it seems hard for the browser to determine whether a DOM element belongs to the initial viewport or not after some user input occurs. Maybe one solution here would be to provide some signal about whether user input has occurred?

Overall I think this is a useful problem to try to tackle: which elements should be considered part of the 'initial viewport'? Optimizing the load times of those with respect to navigation start seems like an important metric. Other elements would need to be optimized with respect to user inputs causing them to become visible in the screen.

[mmocny]

There is indeed a problem with Element Timing reporting and scrolling below-the-fold images and intersectionRect of 0.

Here is a test page: https://fluoridated-bow-church.glitch.me/
And related chromium bug: https://crbug.com/377830100

I think more important than the intersectionRect 0 issue, is that the actual renderTime timings of Element Timing are currently arbitrary, based on UA-specific paint semantics for below the fold content. For example in Chromium, the timings will vary depending on how many "tiles" of paint below the fold Chrome tried to pre-render. (It might also depend on CSS containment properties of the page?).

---

The current conversation thread here proposes reporting relative to an initial viewport-- but I propose an alternative:

1. report a rect/position relative to the whole document, rather than intersection with viewport, once the viewport scrolls.
2. Provide insights whenever an element was rendered lazily, because of viewport.
3. Change Element Timing reporting to be constrained to Intersection with viewport.

---

Ideas:

• Update reporting to include more than just intersectionRect, because this isn't useful for "below-the-fold" content (as mentioned above)
  • We could use the "all 0s" value as a clue that this element was (potentially) lazily rendered.
• Report values of getClientBoundingBox() and window scrollY and scrollX, or just the sum of these, alongside viewport intersectionRect.
• Report the timestamp of when the element triggered Intersection with viewport.
• LCP sub-parts reporting only works well for above-the-fold elements (i.e. the final LCP candidate). But in theory, every element has its own sub-parts which can help here:
  • Right now the 4 breakdowns are expected to cover all the time from timeOrigin to renderTime and expected to all be eager. But for lazy elements we might have idle time for before loading or before rendering.
  • Resource Load Delay assumes the resource is eager to load immediately after document TTFB. For lazy content that isn't true.
    • Idea: Swap document TTFB timestamp to some moment the UA decided to load the element?
    • Idea: Leave reporting as is, but signal that this number was arbitrarily delayed/throttled by viewport and is unimportant.
  • Element render delay assumes that we immediately want to render all elements after they are loaded, but UA might be delaying rendering on purpose. We need an explicit reference startTime.
    • Idea: Leverage Intersection Observer and report viewport intersection time.
    • Idea: Alternatively, report the paintTime of the first animation frame that had this content within viewport.

Also, ideally this would "just work" for content dynamically injected i.e. after Intersection Observer, such that you would know the timing of the intersection and the delays to load and render the element that followed (without having to do explicit task attribution).

[mmocny]

Ah, re-reading the initial issue I think this was originally asking about elements that started in viewport but were scrolled out of it before rendering. I misread.

These are related but might be worth separating. The main difference is that for content that started within the viewport I think the timings are not expected to be lazy (though potentially renderTime might still become lazy if the content is scrolled far enough).