This specification defines an interface to help web developers measure the performance of their applications by giving them access to high precision timestamps.

User Timing Level 2 replaces the first version of [[USER-TIMING]] and includes:

Introduction

Web developers need the ability to assess and understand the performance characteristics of their applications. While JavaScript [ECMA262] provides a mechanism to measure application latency (retrieving the current timestamp from the Date.now() method), the precision of this timestamp varies between user agents.

This document defines the PerformanceMark and PerformanceMeasure interfaces, and extensions to the Performance interface, which expose a high precision, monotonically increasing timestamp so they can better measure the performance characteristics of their applications.

The following script shows how a developer can use the interfaces defined in this document to obtain timing data related to developer scripts.

        async function run() {
          performance.mark("startTask1");
          await doTask1(); // Some developer code
          performance.mark("endTask1");

          performance.mark("startTask2");
          await doTask2(); // Some developer code
          performance.mark("endTask2");

          // Log them out
          const entries = performance.getEntriesByType("mark");
          for (const entry of entries) {
            console.table(entry.toJSON());
          }
        }
        run();
      

[[PERFORMANCE-TIMELINE-2]] defines two mechanisms that can be used to retrieve recorded metrics: getEntries() and getEntriesByType() methods, and the PerformanceObserver interface. The former is best suited for cases where you want to retrieve a particular metric by name at a single point in time, and the latter is optimized for cases where you may want to receive notifications of new metrics as they become available.

Some conformance requirements are phrased as requirements on attributes, methods or objects. Such requirements are to be interpreted as requirements on user agents.

The IDL fragments in this specification MUST be interpreted as required for conforming IDL fragments, as described in the Web IDL specification. [[!WEBIDL]]

User Timing

Extensions to the Performance interface

The Performance interface is defined in [[!HR-TIME-2]].

        partial interface Performance {
            void mark(DOMString markName);
            void clearMarks(optional DOMString markName);
            void measure(DOMString measureName, optional DOMString startMark, optional DOMString endMark);
            void clearMeasures(optional DOMString measureName);
        };
      

mark() method

Stores a timestamp with the associated name (a "mark"). It MUST run these steps:

  1. If the global object is a Window object and markName uses the same name as a read only attribute in the PerformanceTiming interface, throw a SyntaxError.
  2. Create a new PerformanceMark object (entry).
  3. Set entry's name attribute to markName.
  4. Set entry's entryType attribute to DOMString "mark".
  5. Set entry's startTime attribute to the value that would be returned by the Performance object's now() method.
  6. Set entry's duration attribute to 0.
  7. Queue entry.
  8. Add entry to the performance entry buffer.
  9. Return undefined.

clearMarks() method

Removes the stored timestamp with the associated name. It MUST run these steps:

  1. If markName is omitted, remove all PerformanceMark objects from the performance entry buffer.
  2. Otherwise, remove all PerformanceMark objects listed in the performance entry buffer whose name matchesmarkName.
  3. Return undefined.

measure() method

Stores the DOMHighResTimeStamp duration between two marks along with the associated name (a "measure"). It MUST run these steps:

  1. Let end time be 0.
  2. If endMark is omitted, let end time be the value that would be returned by the Performance object's now() method. Otherwise:
    1. If endMark has the same name as a read only attribute in the PerformanceTiming interface, let end time be the value returned by running the convert a name to a timestamp algorithm with name set to the value of endMark.
    2. Otherwise let end time be the value of the startTime attribute from the most recent occurrence of a PerformanceMark object in the performance entry buffer whose name matches the value of endMark. If no matching entry is found, throw a SyntaxError.
  3. If startMark is omitted, let start time be 0. Otherwise:
    1. If startMark has the same name as a read only attribute in the PerformanceTiming interface, let start time be the value returned by running the convert a name to a timestamp algorithm with name set to startMark.
    2. Otherwise let start time be the value of the startTime attribute from the most recent occurrence of a PerformanceMark object in the performance entry buffer whose name matches the value of startMark. If no matching entry is found, throw a SyntaxError.
  4. Create a new PerformanceMeasure object (entry).
  5. Set entry's name attribute to measureName.
  6. Set entry's entryType attribute to DOMString "measure".
  7. Set entry's startTime attribute to start time.
  8. Set entry's duration attribute to the duration from start time to end time. The resulting duration value MAY be negative.
  9. Queue entry.
  10. Add entry to the performance entry buffer.
  11. Return undefined.

clearMeasures() method

Removes stored timestamp with the associated name. It MUST run these steps:

  1. If measureName is omitted, remove all PerformanceMeasure objects in the performance entry buffer.
  2. Otherwise remove all PerformanceMeasure objects listed in the performance entry buffer whose name matches measureName.
  3. Return undefined.

The PerformanceMark Interface

The PerformanceMark interface also exposes marks created via the performance.mark method to the Performance Timeline.

        [Exposed=(Window,Worker)]
        interface PerformanceMark : PerformanceEntry {
        };
      

The PerformanceMark interface extends the following attributes of the PerformanceEntry interface:

The name attribute must return the mark's name.

The entryType attribute must return the DOMString "mark".

The startTime attribute must return a DOMHighResTimeStamp with the mark's time value.

The duration attribute must return a DOMHighResTimeStamp of value 0.

The PerformanceMeasure Interface

The PerformanceMeasure interface also exposes measures created via the performance.measure method to the Performance Timeline.

        [Exposed=(Window,Worker)]
        interface PerformanceMeasure : PerformanceEntry {
        };
      

The PerformanceMeasure interface extends the following attributes of the PerformanceEntry interface:

The name attribute must return the measure's name.

The entryType attribute must return the DOMString "measure".

The startTime attribute must return a DOMHighResTimeStamp with the measure's start mark.

The duration attribute must return a DOMHighResTimeStamp with the duration of the measure.

Processing

Convert a name to a timestamp

To convert a name to a timestamp given a name that is a read only attribute in the PerformanceTiming interface, run these steps:

  1. If the global object is not a Window object, throw a SyntaxError.
  2. If name is navigationStart, return 0.
  3. Let startTime be the value of navigationStart in the PerformanceTiming interface.
  4. Let endTime be the value of name in the PerformanceTiming interface.
  5. If endTime is 0, throw an InvalidAccessError.
  6. Return result of subtracting startTime from endTime.

The PerformanceTiming interface was defined in [[NAVIGATION-TIMING]] and is now considered obsolete. The use of names from the PerformanceTiming interface is supported to remain backwards compatible, but there are no plans to extend this functionality to names in the PerformanceNavigationTiming interface defined in [[NAVIGATION-TIMING-2]] (or other interfaces) in the future.

Privacy and Security

The interfaces defined in this specification expose potentially sensitive timing information on specific JavaScript activity of a page. Please refer to [[HR-TIME-2]] for privacy and security considerations of exposing high-resolution timing information.

Because the web platform has been designed with the invariant that any script included on a page has the same access as any other script included on the same page, regardless of the origin of either scripts, the interfaces defined by this specification do not place any restrictions on recording or retrieval of recorded timing information - i.e. a user timing mark or measure recorded by any script included on the page can be read by any other script running on the same page, regardless of origin.

Acknowledgments

Thanks to James Simonsen, Jason Weber, Nic Jansma, Philippe Le Hegaret, Karen Anderson, Steve Souders, Sigbjorn Vik, Todd Reifsteck, and Tony Gentilcore for their contributions to this work.