Timing issues using Performance API

There could have been three separate issues since each browser has a slightly different misbehavior, though I decided to group everything together as the solution will likely address all problems at once.

tl;dr

Assumptions made in how the SDK computes timestamps are challenged by browsers. We need to revisit the implementation.

Introduction: How span duration and timestamps are computed

The SDK uses performance.now() to calculate span durations with high precision. When sending data to Sentry, we need to convert those durations to absolute timestamps, and in order to keep relative times accurate, we use a single reference timestamp. The preferred reference timestamp is performance.timeOrigin and the fallback is performance.timing.navigationStart.

When the Performance API is not available, the SDK eventually uses Date.now().

The assumption is that reference_timestamp + performance.now() should be close to new Date(), except when the computer’s clock changed or the current tab went into background during a timing measurement (start/end span). The idea was that timestamps would retain relative correctness.

Firefox: timeOrigin != navigationStart

Tested with Firefox 75.0 on macOS.

The equivalence between performance.timeOrigin and performance.timing.navigationStart is discussed in https://github.com/w3c/navigation-timing/issues/43.

However, https://bugzilla.mozilla.org/show_bug.cgi?id=1401406 reports a case in which those clocks do not agree. I’ve observed this behavior today.

• 👍 navigationStart + performance.now() is aligned with the current date and time.
• 👎 timeOrigin is stuck at yesterday’s date, even when I create new browser tabs.
• 👎 The odd timeOrigin in Firefox produces events with incorrect timestamps (arbitrarily in the past).

Safari: navigationStart + now far in the past

Tested with Safari 13.1 (15609.1.20.111.8) on macOS

Since Safari doesn’t support performance.timeOrigin, the SDK falls back to performance.timing.navigationStart.

• 👎 navigationStart + now is over 13 hours off from the current date.

Chrome: timeOrigin + now far in the past

Tested with Chrome 81.0.4044.138 on macOS

• 👍 timeOrigin and navigationStart are the same.
• 👎 timeOrigin + now is over 24h in the past.

[rhcarvalho]

I have experimented with different workarounds, so far it seems to be best to go back to Date.now().

A more complex implementation would use Date.now() and performance.now() to keep track of both timers and make adjustments when a transaction is finished, readjusting all spans, but that complexity doesn’t seem justifiable.

[rhcarvalho]

This blog post https://medium.com/@mihai/performance-now-sleep-16a5b774560c comes with a web page that can easily demo the skewing of the clocks when the computer sleeps.

http://persistent.info/web-experiments/performance-now-sleep/