You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 text was updated successfully, but these errors were encountered:
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 fornavigationEntry
.The text was updated successfully, but these errors were encountered: