performance.now() vs Date.now()

Question

What is the difference between performance.now() and Date.now()?

Should I consider performance.now() as a replacement for Date.now() since performace.now() is more consistent and independent?

Answer 1

They both serve different purposes.

performance.now() is relative to page load and more precise in orders of magnitude. Use cases include benchmarking and other cases where a high-resolution time is required such as media (gaming, audio, video, etc.)

It should be noted that performance.now() is only available in newer browsers (including IE10+).

Date.now() is relative to the Unix epoch (1970-01-01T00:00:00Z) and dependent on system clock. Use cases include same old date manipulation ever since the beginning of JavaScript.

See When milliseconds are not enough: performance.now and now method (Internet Explorer) - MSDN for more information.

The official W3C spec can be found here: High Resolution Time API

Answer 2

Date.now() returns the number of milliseconds elapsed since 1 January 1970 00:00:00 UTC, performance.now() returns the number of milliseconds, with microseconds in the fractional part, from performance.timing.navigationStart, the start of navigation of the document, to the performance.now() call. Another important difference between Date.now() and performance.now() is that the latter is monotonically increasing, so the difference between two calls will never be negative.

For better understanding visit the link.

Answer 3

The first thing I noticed was that performance.now() is 4 times slower than Date.now() (400k operations vs 100k on my computer). However, if you're just counting, using performance.now() is the better option. It's purely dependent on the time since the code started running, and clock changes do not affect the time. It's also more accurate: counting us (microseconds) instead of ms.

As for support, Date.now() has slightly more support than performance.now(), as both are supported by modern browsers, and even IE10/11.

new Date().getTime() has even more support (just a bit) and is 2x slower than Date.now(). It's slower because it creates an object and then calls something.

However, this caniuse.com page shows that performance.now() is almost always okay, in 97.9% (as of right now) of cases.

(From here on out I will only refer to Date.now(), but new Date.getTime() is the same in the cases below)

Usage

Date.now() can (and should) be used for realizing if some time has passed, assuming speed is of (very major) concern: it can easily get the correct frame on a 60fps computer. It can also be used for clocks. It counts how many milliseconds have passed since the Unix Epoch (see the top answer). For applications that require a bit more accuracy (see below), performance.now() can be used. It behaves the exact same as Date.now() if you're using a timer (because it still counts up in milliseconds), except it's more accurate. To use performance.now() as a (slightly) more accurate Date.now() or object, add performance.timing.navigationStart to the value. This does seem to be a few milliseconds off from the Date.now() object, but whose fault it is I'm not sure.

Accuracy

From what I can tell, performance.now() is only 10x more accurate compared to Date.now() on my Chrome desktop: considering time leaps of 0.1ms, However, this accuracy is good enough for most time based applications. (Read the Firefox section for more info on their accuracy) It may look more accurate, but it's not: it is intentionally limited for security reasons, because the exploitation of time could allow malicious users to access other applications.

Firefox

Sadly, this performance (of 0.1ms) is not possible if you have Firefox users and do not have access to Cross-Origin headers. In order to enable it, put the Cross-Origin-Opener-Policy: same-origin and Cross-Origin-Embedder-Policy: require-corp in your document. Users can also increase this speed to 100ms (or higher). Visit the Mozilla documentation for more information.