How Browser Timers Work: Understanding performance.now() vs. Date.now() Precision

When you measure your reaction time, calculate your CPS, or test input latency in a web browser, how can you be certain the numbers are accurate? Can a JavaScript application running inside Google Chrome, Mozilla Firefox, or Apple Safari truly measure events to fractions of a millisecond without being skewed by background tabs, operating system overhead, or CPU clock adjustments?

The answer lies in the fundamental architectural difference between Wall-Clock Time (Date.now()) and Monotonic High-Resolution Time (performance.now()). Understanding this distinction is the cornerstone of building accurate web benchmark utilities.

In this engineering deep dive, we explore how modern browser engines track time, examine why traditional JavaScript clocks fail, analyze the impact of Spectre vulnerability mitigations on timer resolution, and explain how ClickTests.net structures its event listener pipelines for sub-millisecond precision.

1. Wall-Clock Time vs. Monotonic Time: Why Date.now() Fails

Historically, early web developers measured time deltas using Date.now() or new Date().getTime(). This approach seems straightforward: record a timestamp before an action, record another after, and subtract the two:

// The Flawed Legacy Approach
const start = Date.now();
// ... user performs action ...
const elapsed = Date.now() - start; // DANGEROUS FOR BENCHMARKS
      

For scientific benchmarking, Date.now() is fundamentally flawed due to three critical engineering constraints:

1. Wall-Clock Non-Monotonicity (Time Can Jump Backwards)

Date.now() reports the system’s wall-clock time (milliseconds elapsed since January 1, 1970 UTC). This clock is governed by the host operating system and is frequently synchronized with external Network Time Protocol (NTP) servers over the internet. If your operating system syncs its clock during a test, or if daylight savings triggers, or if a user manually adjusts their system time, time can literally jump forward or backwards. In extreme cases, Date.now() - start can return a negative number.

2. Coarse Windows Timer Resolution (The 15.6ms Bottleneck)

On Windows operating systems, the standard system timer interrupt operates at 64Hz (15.625 milliseconds). Unless an active application explicitly requests a higher multimedia timer resolution (via timeBeginPeriod), Date.now() updates only once every 15.6ms. If an event occurs 3ms after another, Date.now() may report that 0ms elapsed, completely destroying the accuracy of a click speed or reaction benchmark.

2. Enter the High Resolution Time API (performance.now())

To eliminate these limitations, the W3C Web Performance Working Group standardized the High Resolution Time API, exposing window.performance.now().

performance.now() differs from Date.now() in two revolutionary ways:

1. It Is Strictly Monotonic: performance.now() does not reference the calendar year. Instead, it measures time elapsed since performance.timeOrigin (the moment the document navigation began). The clock ticks forward at a constant rate tied to the CPU’s hardware High Precision Event Timer (HPET) or Time Stamp Counter (TSC). It never jumps backwards, regardless of system clock changes or NTP adjustments.
2. Floating-Point Sub-Millisecond Precision: While Date.now() returns an integer, performance.now() returns a double-precision floating-point number representing milliseconds with microsecond fractions (e.g., 1420.354000 ms).

3. The Spectre Vulnerability: Why Modern Browsers Clamp Precision

When the High Resolution Time API debuted, performance.now() provided true nanosecond resolution (0.000001ms). However, in January 2018, computer security researchers uncovered Spectre (CVE-2017-5753)—a critical speculative execution hardware vulnerability affecting modern Intel, AMD, and ARM processors.

Spectre exploits rely on side-channel cache timing attacks: an attacker measures the exact CPU cache access latency down to nanoseconds to infer secret memory contents across browser security boundaries. Because a microsecond-accurate clock was the primary tool needed to execute Spectre in JavaScript, every major browser vendor intervened:

• Precision Clamping: Google Chrome, Mozilla Firefox, and Apple Safari intentionally reduced timer resolution, rounding timestamps to 5 microseconds (0.005ms) or 20 microseconds (0.02ms) depending on platform.
• Timer Jitter: Browsers inject subtle random pseudo-noise (jitter) into the lowest decimal places to thwart cache timing attacks.

4. event.timeStamp vs. performance.now(): The Critical Input Difference

One of the most frequent mistakes made by amateur benchmark developers is calling performance.now() inside an event listener:

// ❌ WRONG: Skewed by Event Loop Queue Delay
button.addEventListener('mousedown', () => {
  const clickTime = performance.now(); // Captures when JS executed, NOT when clicked!
});

// ✅ CORRECT (ClickTests.net Architecture):
button.addEventListener('mousedown', (event) => {
  const hardwareTime = event.timeStamp; // Captures actual OS hardware interrupt time!
});
      

Why event.timeStamp is Superior

The browser’s main thread is single-threaded. If the browser is parsing HTML, executing layout reflow, or running a garbage collection cycle when you click, your JavaScript event listener cannot run immediately. It must wait in the Task Queue until the main thread frees up.

If you call performance.now() inside the handler, your recorded time includes the task queue queuing delay (which can be 2ms to 15ms of artificial jitter). But event.timeStamp is populated directly by the browser's native C++ input compositor thread the instant the operating system delivers the raw USB hardware packet, bypassing JavaScript event loop queue delays.

5. Mousedown vs. Click Events: Eliminating the Release Delay

In standard DOM specifications, the generic click event does not fire when your finger pushes the mouse button down. The click event fires only after the complete cycle: button down → button released.

The physical act of releasing a finger takes humans roughly 40 to 90 milliseconds. Furthermore, on touchscreens, legacy mobile browsers enforced a notorious 300ms tap delay to check for double-tap zoom gestures.

6. Web Timing Mechanism Comparison Table

7. Summary: Why You Can Trust ClickTests.net Measurements

When you benchmark your speed on ClickTests.net, your results are generated locally inside your browser using pure hardware-level event timestamps (event.timeStamp) measured against monotonic high-resolution clocks (performance.now()). There are zero network round-trips, zero server latency skews, and zero release-delay penalties.