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 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:
Perhaps less often considered is that
Date, based on system time, isn't ideal for real user monitoring either. Most systems run a daemon which regularly synchronizes the time. It is common for the clock to be tweaked a few milliseconds every 15-20 minutes. At that rate about 1% of 10 second intervals measured would be inaccurate.
There are a few situations where you'd use this high resolution timer instead of grabbing a basic timestamp:
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.
navigationStartof the page rather than to the UNIX epoch