So just to compare, here are the sorts of values you'd get back:
Date.now() // 1337376068250
performance.now() // 20303.427000007
You'll notice the two above values are many orders of magnitude different.
performance.now() is a measurement of floating point milliseconds since that particular page started to load (the
performance.timing.[navigationStart](https://www.w3.org/TR/navigation-timing/#dom-performancetiming-navigationstart) timeStamp to be specific). You could argue that it could have been the number of milliseconds since the unix epoch, but rarely does a web app need to know the distance between now and 1970. This number stays relative to the page because you'll be comparing two or more measurements against eachother.
Another added benefit here is that you can rely on the time being monotonic. Let's let WebKit engineer Tony Gentilcore explain this one:
There are a few situations where you'd use this high resolution timer instead of grabbing a basic timestamp:
- game or animation runloop code
- calculating framerate with precision
- cueing actions or audio to occur at specific points in an animation or other time-based sequence
The high resolution timer is currently available in Chrome (Stable) as
window.performance.webkitNow(), and this value is generally equal to the new argument value passed into the requestAnimationFrame callback. Pretty soon, WebKit will drop its prefix and this will be available through
performance.now(). The WebPerfWG in particular, led by Jatinder Mann of Microsoft, has been very successful in unprefixing their features quite quickly.
- a double with microseconds in the fractional
- relative to the
navigationStartof the page rather than to the UNIX epoch
- not skewed when the system time changes
- available in Chrome stable, Firefox 15+, and IE10.