search

WICG / element-timing

A proposal for an Element Timing specification.
https://wicg.github.io/element-timing/
Other
57 stars 15 forks source link

Report image Element Timing algorithm doesn't report intrinsic size for LCP #31

Open philipwalton opened 5 years ago

philipwalton commented 5 years ago

My understanding is LCP is supposed to factor in the intrinsic sizes of images and not consider the rendered size for LCP in cases where the image is stretched or enlarged (e.g. a 1px transparent gif).

But as currently spec'ed, the natural width and height of the image are set after 3.5 sub-item 3:

If exposedElement is not null, call the potentially add a LargestContentfulPaint entry algorithm with intersectionRect, imageRequest, renderTime, loadTime, element, and document.

At this point in the algorithm, intersectionRect has only considered the visual width and height, not the intrinsic width and height, thus 3 sub-item 9 in the LCP spec will report the visual size, which I do not believe is the intention.

Let size be width*height.

philipwalton commented 5 years ago

One other note. The current Chrome implementation doesn't consider image scaling of CSS background images.

I believe the intention is to have scaled background images report the same as they would if they were an <img> tag, so whatever language is used to report these to LCP should also address background images resized via the background-size property.

npm1 commented 5 years ago

I'll address the original issue on the LCP side by scaling the size by min(display_size, intrinsic_size) / display_size.

Regarding the background-size not being captured in Chrome comment, can you file a new bug in crbug.com/new?