Navigation timing end events coming before start events

[scottgifford]

Hello,

I am seeing a small but consistent number of metrics recorded by Boomerang where the ending timestamp comes before the starting timestamp, which is triggering an error when processing these later. For more details see boomerang-negative-duration-20210416.txt

I was wondering if other people saw this too, and if there is anything to be done about it besides ignore these metrics?

I'm seeing this in a wide variety of browsers, many of which are old but some of which are newer (Firefox 88, Safari 13.1.2).

Thanks for any thoughts!

----Scott.

[bluesmoon]

Have you rules out fake beacons?

[scottgifford]

Hm no, any advice on how to rule those out?

[bluesmoon]

This page should have some information: https://developer.akamai.com/tools/boomerang/docs/tutorial-howto-read-data-from-a-beacon.html

[scottgifford]

I took a look at some of the data. The requests we are getting from the client line up with the request IDs we generated on our backend (effectively the nonce suggested by the above link); I do not see any wrong Referers (most are correct and a few are blank); and the other data fields for those requests seem normal. So it does not seem likely they are completely bogus beacons.

[nicjansma]

@scottgifford we've seen a lot of issues in the past (especially with older browsers) where timestamps just didn't make sense. Some of those have bugs filed and are recorded here:

https://nicj.net/navigationtiming-in-practice/#navtiming-browser-bugs

I suggest in that "If you’re analyzing NavigationTiming data, you should ensure that all timestamps increment according to the timeline. If not, you should probably question all of the timestamps and discard.", which is more-or-less what we do with data coming into mPulse.