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 want accurate timing/time since page load, 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 tenths of a millisecond instead of milliseconds.

TL;DR

On non-Firefox browsers, Date.now() is accurate to ~1ms and performance.now() is accurate to ~0.1ms unless in certain cases. If you're using Firefox, the accuracy is down for both to 2ms. They are both extremely fast.

Support and Speed

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

new Date().getTime() has just a bit more support and is 2x slower than Date.now(). It's slower, because it creates a big object, but only calls a single function.

However, this caniuse.com page shows that performance.now() is almost always okay, in 98.25% (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 delta time (particularly requestAnimationFrame(): it can easily get the correct frame on a 120fps display! It can also be used as a clock. It counts how many milliseconds have passed since the Unix Epoch (see the top answer for more details).

A particularly interesting use case is calling Date.now() multiple times in one frame in order to stop calculations after a certain amount of time has passed. As Date.now() is pretty fast, this shouldn't be much of an issue.

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 (usually) 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 as to why I'm not sure. Just don't combine the two

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-strict applications. (Read the Firefox section for more info on their accuracy.) It may look more accurate (like 313015.59999999404), but it's not: it is intentionally limited for security reasons, because the exploitation of time could allow malicious code to access other applications. If you want it to not show up in such an ugly way, you can use performance.now().toFixed(1) to make it more accurate. You can also make this a Number by adding a plus sign to the start: +performance.now().toFixed(1) should work.

Firefox

Sadly, this performance (of 0.1ms) is not possible if you have Firefox users and do not have access to Cross-Origin headers. Instead, you can only get an accuracy of 2ms (also the same as Date.now()!) 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.