The Workers runtime supports a subset of thePerformance API ↗, used to measure timing and performance, as well as timing of subrequests and other operations.

Theperformance.now() method ↗ returns timestamp in milliseconds, representing the time elapsed sinceperformance.timeOrigin.

When Workers are deployed to Cloudflare, as a security measure tomitigate against Spectre attacks, APIs that return timers, includingperformance.now() ↗ andDate.now() ↗, only advance or increment after I/O occurs. Consider the following examples:

conststart=performance.now();
for (leti=0;i<1e6;i++){
// do expensive work
}
constend=performance.now();
consttiming=end-start;// 0

conststart=performance.now();
constresponse=awaitfetch("https://developers.cloudflare.com/");
constend=performance.now();
consttiming=end-start;// duration of the subrequest to developers.cloudflare.com

By wrapping a subrequest in calls toperformance.now() orDate.now() APIs, you can measure the timing of a subrequest, fetching a key from KV, an object from R2, or any other form of I/O in your Worker.

In local development, however, timers will increment regardless of whether I/O happens or not. This means that if you need to measure timing of a piece of code that is CPU intensive, that does not involve I/O, you can run your Worker locally, viaWrangler, which uses the open-source Workers runtime,workerd ↗ — the same runtime that your Worker runs in when deployed to Cloudflare.

Theperformance.timeOrigin ↗ API is a read-only property that returns a baseline timestamp to base other measurements off of.

In the Workers runtime, thetimeOrigin property returns 0.