Update LCP attribution to handle the first frames of animated content

[rviscomi]

As of Chrome 116, the LCP definition accounts for the first painted frame of an animated image or video. However, due to a bug in the rollout, this change has not actually taken effect in the LCP API yet.

When fixed, this change means that the LCP time can occur before the LCP resource has finished loading. The LCP phases in the attribution object would need to be updated to handle these cases, specifically resource load duration and render delay, which are both calculated based on the lcpResponseEnd time. In the current implementation, the sum of the LCP phases would exceed the total LCP time.

The attribution code could detect when this happens by checking to see if the LCP time falls within the load duration phase. When detected, load duration could end at the first byte time of the resource response (lcpResourceEntry.responseStart), and render delay set from that moment to the LCP time. Alternatively, if responseStart isn't available, for example if the resource is cross-origin and there's no TAO, the load duration could be capped at LCP time and render delay set to 0.

[philipwalton]

My preference would be for option 2 (cap load duration at LCP time). I'd rather under report render delay than misattribute download time to that phase. WDYT?

[rviscomi]

Either or both SGTM. There may also be some extreme cases where the resource is prefetched and rendering is delayed by something unrelated, but I do like the consistency of the second approach regardless of TAO.

[elitesuper]

I agree with @philipwalton, capping the load duration at LCP time seems like the most reliable approach, even if it might slightly underreport render delay.