Why would you use performance.now() instead of Date.now() to measure how long a function takes to run?

**Target Audience:** Engineers preparing for JavaScript performance-measurement interview questions. **Difficulty:** Medium > **How to read this doc:** Concepts are explained in plain language first, then tagged with 📌 Interview term: . Every result below was actually run on Node.js v24.19.0 — the printed output is real, captured output, not illustrative sample text. ## 1. Why This Even Matters — A Story First Imagine timing a race two different ways. One timer is a wall clock that only displays whole minutes and can be nudged forward or back if someone resets it against a radio time signal mid-race. The other is a dedicated stopwatch built for exactly this job -- it shows fractions of a second, and its hands only ever move forward, completely unaffected by anything happening to the wall clock nearby. `Date.now()` is the wall clock; `performance.now()` is the purpose-built stopwatch. ## 2. The Core Idea 📌 **Interview term:** `performance.now()` returns a floating-poi

Tricky JavaScript Scenario #65: High Resolution Time API precision

01

Understand the problem

Question presented to candidate: "If you wanted to measure how long a function takes to run, why would you reach for performance.now() instead of just calling Date.now() before and after it?"

What a strong answer should cover:

performance.now() returns a high-resolution timestamp, expressed as a float with sub-millisecond precision, relative to a fixed time origin -- not an absolute epoch value.
Date.now() returns whole milliseconds since the Unix epoch and is tied to the system wall clock, which can be adjusted (NTP sync, manual changes) while a measurement is in progress.
performance.now() is implemented as a monotonic clock -- it never goes backward, so it stays safe for measuring elapsed durations even if the wall clock is adjusted mid-measurement, unlike Date.now().
For a genuinely fast operation, Date.now() can report a 0ms delta simply because the operation finished inside the same millisecond tick, while performance.now() can report real, non-zero sub-millisecond timing for that same operation.
Real caveat worth naming: browsers deliberately coarsen and jitter performance.now()'s resolution as a Spectre-era security mitigation, so its resolution is not unlimited in a browser the way it can appear to be in a Node.js process.

Clarifying questions expected:

"Is this for browser code, Node.js code, or both -- the security-driven resolution coarsening only applies inside browsers."

Code / implementation expected: Yes -- a runnable snippet comparing both clocks' resolution and timing the same fast operation with each.

perf-apitrickyreal-world

02

Attempt it yourself

Sketch your approach before reading the solution — that's what interviews test.

Nudge consolestandby

Stuck? Beam a request up — the console returns a conceptual nudge that guides your logic without spoiling the implementation.

03

Study the solution

Target Audience: Engineers preparing for JavaScript performance-measurement interview questions. Difficulty: Medium

How to read this doc: Concepts are explained in plain language first, then tagged with 📌 Interview term:. Every result below was actually run on Node.js v24.19.0 — the printed

Solution ready — 2 min read

Classified // press E to declassify

04

Run the code

JSDate.now() vs performance.now(): resolution, timing, and monotonicity (run directly)

Practice

05

Join the discussion

Discussion (0)

Sign in to join the discussion.

No responses yet. Be the first to share what you think.