Open yoavweiss opened 9 months ago
Makes sense to me.
LoAF has a similar idea in its "firstUIEventTimestamp".
In a perfect world, we would directly link to an Event Timing entry and/or interactionID, but you can use event.timeStamp and event.type to == on EventTiming.startTime and EventTiming.name -- and then you don't have to wait for presentation time (LoAF has the same issue)
At #14 we decided that the best
startTime
timestamp is at the processing end, as it toughly matches (even if not precisely) what other navigations are doing on the platform.But, talking to @noamr, he made the argument that it'd be good to have a less ambigous timestamp that would enable various future comparisons - the hardward timestamp.
So, we talked about exposing an
interactionToStartTime
measurement, that would represent the duration between the hardware timestamp andstartTime
. It may be interesting to also expose the same as part of NavigationTiming.^^ @mmocny @iclelland