W3C Updates High Resolution Time Draft: What JavaScript Performance Measurements Need to Get Right

The W3C Web Performance Working Group published a new High Resolution Time Working Draft  on November 6, 2026. The document describes how web applications obtain a stable time origin and measure elapsed time with the performance API, including behavior across browser contexts and safeguards that limit timer precision.

The key distinction is that this is a Working Draft, not a new browser release or a final W3C Recommendation. Its publication does not mean every browser gained a new timer feature on November 6. For developers, the document offers a useful opportunity to revisit a common testing mistake: using wall-clock time to measure tiny bits of JavaScript work.

Why performance.now() is different from Date.now()

Date.now() gives a wall-clock timestamp. That is useful for showing the date and time, but it is a poor basis for measuring durations because the operating system clock may be adjusted. A sequence of wall-clock readings can therefore produce distorted results.

performance.now() measures elapsed time relative to a time origin, based on a monotonic clock. This makes it better suited to measuring operations such as rendering a component, transforming local text, or evaluating an algorithm. The draft also defines performance.timeOrigin to help relate timing information from different execution contexts.

For a quick inspection in browser DevTools:

const start = performance.now();
const result = JSON.stringify({ name: 'example', values: [1, 2, 3] });
const elapsed = performance.now() - start;
console.log({ codeUnits: result.length, elapsedMs: elapsed });

The codeUnits value is the JavaScript string length, not its encoded byte size. This demonstration measures a tiny, illustrative operation. Such small timings can be dominated by noise, JIT compilation, garbage collection, browser scheduling, and timer granularity. Run representative workloads repeatedly and compare distributions, not one attractive decimal number.

More digits do not guarantee more precision

The W3C draft discusses coarsening timer values, including permitted implementation-defined choices for resolution and jitter. Browsers can reduce timer precision for privacy and security, since extremely fine-grained timers can help some side-channel attacks.

The draft describes a 100-microsecond baseline for coarsening, with a 5-microsecond value in cross-origin-isolated contexts, while allowing implementations to expose lower precision. Those are specifications of the algorithm, not guaranteed real-world accuracy for every browser and device. A JavaScript number containing many decimal places is not evidence that the clock is accurate to those places.

For teams building benchmarking or profiling tools, that distinction matters. A difference of a few microseconds may not be meaningful when the timer is deliberately rounded or when the workload runs inside a busy browser tab.

Page and worker clocks require care

A web app may measure work both on its main thread and in a Web Worker. The elapsed duration within each context is useful, but timestamps from separate time origins should not simply be subtracted. The W3C draft explains how performance.timeOrigin can help translate timestamps for a shared timeline within contexts that can communicate.

For example, a worker can report an approximately epoch-relative timestamp using performance.timeOrigin + performance.now(). The page can convert it to a timestamp relative to its own time origin. This is useful for visualization, but developers should still account for communication delay, clock coarsening, and restrictions across browser sessions.

For direct measurements, the browser’s Performance panel remains the more complete view of long tasks, rendering, and main-thread contention. If you document worker interactions, the Mermaid diagram editor can help you illustrate when a worker message is sent, processed, and received.

What website and tool developers can do now

Start with a specific question. If an HTML transformation seems slow, time the transformation separately from page rendering and file download. If an API seems slow, distinguish the server’s HTTP response from client-side parsing and rendering. The Web2Generators network inspection guide explains where to inspect request and response details across major browsers.

For HTTP-only checks, the cURL command line builder helps prepare a repeatable request. cURL cannot measure JavaScript execution inside the browser; use it for a complementary view of request behavior, not as a replacement for browser profiling.

If optimizing page markup, the HTML minifier provides a practical before-and-after size comparison. Our HTML minifier announcement explains the difference between source-size savings and compressed transfers. Measure resulting real page behavior as well, since fewer source bytes do not automatically imply faster JavaScript or better user experience.

A standards update, not a migration deadline

There is no immediate migration requirement attached to this Working Draft. Teams should continue using supported Performance APIs, measure representative workloads, and avoid assuming sub-millisecond accuracy merely because the API exposes fractions of a millisecond. Track the W3C specification  and browser compatibility information for later changes.