Add intersectionRect (from element timing) to LCP?

[mmocny]

LCP entries expose a size but not an intersectionRect.

Is there a specific reason?

Having the full rect is quite useful especially for cases such as:

• the element becomes null for reporting
• the sizing of the element is constrained to a bounding box that does not match getBoundingClientRect()
  • (and as far as I know getting a tight bounding box is really hard and involves manually parsing computed styles)
• Useful to visualize cases when surprising candidates or sizes are computed (i.e. when there are nested inline text nodes, etc).

[mmocny]

Looking at the algorithm for LCP, it is explicitly taking an intersectionRect as computed by element timing and then converting just to a single size:

https://w3c.github.io/largest-contentful-paint/#potentially-add-a-largestcontentfulpaint-entry

[mmocny]

...meanwhile element timing does not expose size.

I think these entry types should try to be as similar as possible, no? Then you can share a sinlge PerformanceObserver, for example.

[clelland]

I agree; this would have been really useful in a number of debugging situations. I don't know if this was an oversight in the original design or not, but it would be a useful addition now.

[bdekoz]

agree. Moz has an existing feature request for a use case for Michal's third point above, aka "Useful to visualize cases when surprising candidates.."

[mmocny]

Excellent! I'll ask if we can add to the WG meeting schedule, just to confirm this is not intentional for some obscure historical reason.

Should be trivial to patch into spec.