timeOrigin

WHAT IS THE MEANING OF TIME!?!?!

Nic Jansma @nicj

In the beginning...

There was:

​

> performance.timing.navigationStart

1686231991133

​

(... and there still is! but it's now ⭐deprecated⭐)

And he had a friend, the DOMHighResTimeStamp

> performance.now()

202103

​

> performance.getEntriesByType("resource").map( r => r.startTime)[0]

814.1999998092651

With their powers combined, you can CALCULATE TIME!

I don't always do math, but when I do, I do it against the Unix Epoch:

​

> performance.now() + performance.timing.navigationStart

202103 + 1686231991133 = 1686232320745.4

​

> new Date(performance.now() + performance.timing.navigationStart)

Thu Jun 08 2023 09:52:00 GMT-0400 (Eastern Daylight Time) // nowish

Then we said...

Let there be .timeOrigin!

​

> performance.timeOrigin

1686231991133.2

​

And then we saw the light! (of microseconds^(optional))

(and then we deprecated performance.timing.*)

So let's switch!

Use the modern interface first:

> var timeOrigin =� performance.timeOrigin || � (performance.timing || {}).navigationStart ||� new Date().getTime(); // via Request Metrics

​

> new Date(performance.now() + myTimeOrigin)

// nowish???

Challenge #1: Confusion

What does it mean when they're different?

Firefox 114:

​

Safari 16.4:

​

​

Chrome:

​

Challenge #1: Confusion

What does it mean when they're different?

​

​

​

• Relationship between performance.timing.navigationStart and hr-time time origin
• Using navigationStart as a baseline may expose cross-origin timing information #160
• performance.timeOrigin vs performance.timing.navigationStart

Challenge #1: Confusion

Can they be different?

The one case maybe from the spec is on browser launch of the first nav:

The time origin is the time value from which time is measured: ... the time when the browsing context is first created if there is no previous document; ...

https://www.w3.org/TR/hr-time-2/#sec-time-origin

Challenge #2: Browser Bugs: Chrome

Process start time?

https://bugs.chromium.org/p/chromium/issues/detail?id=1365808

This issue is a really serious problem for us, if I’m understanding correctly that performance.timeOrigin is no longer a reliable measurement for the time origin of a web page being opened.

We use performance.timeOrigin for client performance measurements that we collect and persist in a database for analysis. This issue means that starting with 105 we now potentially have a pile of corrupted/dirty data mixed in with the rest, with no way to tell the good from the bad across literally thousands of customers.

This is a catastrophe for this use case. Can a fix for this be prioritized more highly? Every day that passes, we’re collecting more and more bad data mixed in with the good.

​

FIXED

Challenge #2: Browser Bugs: Firefox

Process start time?

• performance.timeOrigin is set from the system clock (once per process) instead of a shared monotonic clock, which is inconsistent with the High Resolution Time spec
• https://bugzilla.mozilla.org/show_bug.cgi?id=1710762
• Timing issues using Performance API

​

Examples of 10ms, 400ms, 75,000,000ms (20 hr) difference between .timeOrigin and .navigationStart

Challenge #2: Browser Bugs: Safari

Safari Drift

.timeOrigin is changing over time

​

https://bugs.webkit.org/show_bug.cgi?id=258572

Challenge #3: vs. .startTime?

vs. NavigationTimingEntry.startTime

If .timeOrigin != .navigationStart, shouldn't the "navigation" entry's .startTime not be 0?

​

Summary

• Should .timeOrigin and .timing.navigationStart be the same?
• ... yes?
• Browser bugs
• Some fixed, some in progress, some need to be filed
• Result = RUM can't reliably use .timeOrigin at all
• But using the "deprecated" .timing.navigationStart interface