The answer to "why was my LCP slow" can sometimes be found in the sub-TTFB diagnostics, so it'd be useful for that data to be available in the LCP attribution object. This would ensure that the data can be included in the same analytics payload as the rest of the LCP info, avoiding the need to join the records on the backend if TTFB and LCP were sent separately. While the raw navigation entry is already made available, and the attribution logic is pretty straightforward, it still seems redundant for the client to do that work in the LCP handler.
There could be a new timeToFirstByteAttribution property added to LCP's attribution object, whose value could be the five duration properties provided by TTFB attribution, i.e. everything except for navigationEntry.
The answer to "why was my LCP slow" can sometimes be found in the sub-TTFB diagnostics, so it'd be useful for that data to be available in the LCP attribution object. This would ensure that the data can be included in the same analytics payload as the rest of the LCP info, avoiding the need to join the records on the backend if TTFB and LCP were sent separately. While the raw navigation entry is already made available, and the attribution logic is pretty straightforward, it still seems redundant for the client to do that work in the LCP handler.
There could be a new
timeToFirstByteAttributionproperty added to LCP's attribution object, whose value could be the five duration properties provided by TTFB attribution, i.e. everything except fornavigationEntry.