Abstract

This specification extends the High Resolution Time specification [HR-TIME-2] by providing methods to store and retrieve high resolution performance metric data.

Status of This Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This new version is aligned with [HR-TIME-2] and introduces filtering and performance observers.

This is a work in progress and may change without any notices.

This document was published by the Web Performance Working Group as a Working Draft. This document is intended to become a W3C Recommendation. If you wish to make comments regarding this document, please send them to public-web-perf@w3.org (subscribe, archives) with [Performance Timeline] at the start of your email's subject. All comments are welcome.

Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

This document is governed by the 1 September 2015 W3C Process Document.

Table of Contents

1. Introduction

This section is non-normative.

Accurately measuring performance characteristics of web applications is an important aspect of making web applications faster. This specification defines the necessary Performance Timeline primitives that enable web developers to access, instrument, and retrieve various performance metrics from the full lifecycle of a web application.

[NAVIGATION-TIMING-2], [RESOURCE-TIMING], and [USER-TIMING] are examples of specifications that define timing information related to the navigation of the document, resources on the page, and developer scripts, respectively. Together these and other performance interfaces define performance metrics that describe the Performance Timeline of a web application. For example, the following script shows how a developer can access the Performance Timeline to obtain performance metrics related to the navigation of the document, resources on the page, and developer scripts:

Example 1
<!doctype html>
<html>
<head>
</head>
<body onload="init()">
<img id="image0" src="https://www.w3.org/Icons/w3c_main.png" />
<script>
   function init()
   {
        performance.mark("startWork"); // see [[User Timing]]
        doWork(); // Some developer code
        performance.mark("endWork");
        measurePerf();
   }
   function measurePerf()
   {
       var perfEntries = performance.getEntries();
       for (var i = 0; i < perfEntries.length; i++)
       {
             if (window.console) console.log("Name: "        + perfEntries[i].name      +
                                             " Entry Type: " + perfEntries[i].entryType +
                                             " Start Time: " + perfEntries[i].startTime +
                                             " Duration: "   + perfEntries[i].duration  + "\n");
       }
   }
</script>
</body>
</html>

Alternatively, instead of processing metrics at a predefined time, or having to periodically poll the timeline for new metrics, the developer may also observe the Performance Timeline and be notified of new performance metrics via a Performance Observer:

Example 2
<!doctype html>
<html>
<head>
</head>
<body>
<img id="image0" src="https://www.w3.org/Icons/w3c_main.png" />
<script>
var observer = new PerformanceObserver(function(list) {
  var doneObservingEvents = false;
  var perfEntries = list.getEntries();
  for (var i = 0; i < perfEntries.length; i++)
  {
       if (window.console) console.log("Name: "        + perfEntries[i].name      +
                                       " Entry Type: " + perfEntries[i].entryType +
                                       " Start Time: " + perfEntries[i].startTime +
                                       " Duration: "   + perfEntries[i].duration  + "\n");
  }
  // maybe disconnect after processing the events.
  if (doneObservingEvents) {
       observer.disconnect();
  }
});
// subscribe to Frame-Timing and User-Timing events
observer.observe({entryTypes: ['frame', 'mark', 'measure']});
</script>
</body>
</html>

2. Conformance

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key words MUST and MUST NOT are to be interpreted as described in [RFC2119].

Conformance requirements phrased as algorithms or specific steps may be implemented in any manner, so long as the end result is equivalent. (In particular, the algorithms defined in this specification are intended to be easy to follow, and not intended to be performant.)

The IDL fragments in this specification must be interpreted as required for conforming IDL fragments, as described in the Web IDL specification. [WebIDL]

3. Performance Timeline

Each ECMAScript global environment has a performance observer task queued flag and an associated list of registered performance observer objects which is initially empty.

To queue a PerformanceEntry (new entry), run these steps:

  1. Let interested observers be an initially empty set of PerformanceObserver objects.
  2. For each registered performance observer (observer):
    1. If observer's PerformanceObserverInit entryTypes includes new entry’s entryType value, append observer to interested observers.
  3. For each observer in interested observers:
    1. Append new entry to observer buffer.
  4. If the performance observer task queued flag is set, terminate these steps.
  5. Set performance observer task queued flag.
  6. Queue a task that consists of running the following substeps. The task source for the queued task is the performance timeline task source.
    1. Unset performance observer task queued flag.
    2. Let notify list be a copy of ECMAScript global environment's list of registered performance observer objects.
    3. For each PerformanceObserver object po in notify list, run these steps:
      1. Let entries be a copy of po’s observer buffer.
      2. Empty po’s observer buffer.
      3. If entries is non-empty, call po’s callback with entries as first argument and callback this value. If this throws an exception, report the exception.

The performance timeline task queue is a low priority queue that, if possible, should be processed by the user agent during idle periods to minimize impact of performance monitoring code.

3.1 The PerformanceEntry interface

The PerformanceEntry interface hosts the performance data of various metrics.

[Exposed=(Window,Worker)]
interface PerformanceEntry {
    readonly    attribute DOMString           name;
    readonly    attribute DOMString           entryType;
    readonly    attribute DOMHighResTimeStamp startTime;
    readonly    attribute DOMHighResTimeStamp duration;
    serializer = {attribute};
};

3.1.1 Attributes

duration of type DOMHighResTimeStamp, readonly
The attribute MUST return a DOMHighResTimeStamp that contains the time value of the duration of the entire event being recorded by this PerformanceEntry. Typically, this would be the time difference between the last recorded timestamp and the first recorded timestamp of this PerformanceEntry. If the duration concept doesn't apply, a performance metric may choose to return a duration of 0.
entryType of type DOMString, readonly
This attribute MUST return the DOMString that describes the type of the interface represented by this PerformanceEntry object.
Note

Valid entryType values are: mark [USER-TIMING], measure [USER-TIMING], navigation [NAVIGATION-TIMING-2], frame [FRAME-TIMING], resource [RESOURCE-TIMING], server [SERVER-TIMING].

name of type DOMString, readonly
The attribute MUST return a DOMString identifier for this PerformanceEntry object. This identifier does not have to be unique.
startTime of type DOMHighResTimeStamp, readonly
The attribute MUST return a DOMHighResTimeStamp that contains the time value of the first recorded timestamp of this performance metric.

3.1.2 Serializer

Instances of this interface are serialized as a map with entries for each of the serializable attributes.

3.2 Extensions to the Performance interface

This extends the Performance interface [HR-TIME-2] and hosts performance related attributes and methods used to retrieve the performance metric data from the Performance Timeline.

dictionary PerformanceEntryFilterOptions {
             DOMString name;
             DOMString entryType;
             DOMString initiatorType;
};

3.2.1 Dictionary PerformanceEntryFilterOptions Members

entryType of type DOMString,
entryType of PerformanceEntry object.
initiatorType of type DOMString,
initiatorType of PerformanceResourceTiming object.
name of type DOMString,
name of PerformanceEntry object. 
partial interface Performance {
    PerformanceEntryList getEntries (optional PerformanceEntryFilterOptions filter);
    PerformanceEntryList getEntriesByType (DOMString type);
    PerformanceEntryList getEntriesByName (DOMString name, optional DOMString type);
};

3.2.2 Methods

getEntries

This method returns a PerformanceEntryList object that contains a list of PerformanceEntry objects, sorted in chronological order with respect to startTime, that match the following criteria:

  1. Let the list of entry objects be the empty PerformanceEntryList.
  2. Let the set of filter properties be a set of pairs where the first element is the name of a dictionary member of filter that is present and the second element is the value of that dictionary member.
  3. For each PerformanceEntry object (entryObject) associated with the context object, in chronological order with respect to startTime:
    1. For each name and value pair in set of filter properties:
      1. If the entryObject does not contain an attribute whose name matches name, go to next entryObject.
      2. Otherwise, if the entryObject contains an attribute whose name matches name, and its value does not match value, go to next entryObject.
    2. Add entryObject to the list of entry objects.
  4. Return the list of entry objects.
ParameterTypeNullableOptionalDescription
filterPerformanceEntryFilterOptions✘✔
getEntriesByName
This method returns a PerformanceEntryList object returned by getEntries({'name': name}) if optional entryType is omitted, and getEntries({'name': name, 'entryType': type}) otherwise.
ParameterTypeNullableOptionalDescription
nameDOMString✘✘
typeDOMString✘✔
getEntriesByType
This method returns a PerformanceEntryList object returned by getEntries({'entryType': type}).
ParameterTypeNullableOptionalDescription
typeDOMString✘✘
typedef sequence<PerformanceEntry> PerformanceEntryList;
Throughout this specification, the identifier PerformanceEntryList is used to refer to the sequence<PerformanceEntry> type.

3.3 The Performance Observer interface

The PerformanceObserver interface can be used to observe the Performance Timeline and be notified of new performance entries as they are recorded by the user agent.

Each PerformanceObserver has these associated concepts:

The PerformanceObserver(callback) constructor must create a new PerformanceObserver object with callback set to callback and then return it.

A registered performance observer consists of an observer (a PerformanceObserver object) and options (a PerformanceObserverInit dictionary).

callback PerformanceObserverCallback = void (PerformanceObserverEntryList entries, PerformanceObserver observer) ();
[Constructor(PerformanceObserverCallback callback), Exposed=(Window,Worker)]
interface PerformanceObserver {
    void observe (PerformanceObserverInit options);
    void disconnect ();
};

3.3.1 Methods

disconnect
This method must remove the context object from the list of PerformanceObserver objects associated with the ECMAScript global environment of the interface object, and also empty context object's observer buffer.
No parameters.
Return type: void
observe
dictionary PerformanceObserverInit {
    required sequence<DOMString> entryTypes;
};
Dictionary PerformanceObserverInit Members
entryTypes of type sequence<DOMString>, required

A list of valid entryType names to be observed. The list MUST NOT be empty and types not recognized by the user agent MUST be ignored.

Note

To keep the performance overhead to minimum the application should only subscribe to event types that it is interested in, and disconnect the observer once it no longer needs to observe the performance data. Filtering by name is not supported, as it would implicitly require a subscription for all event types — this is possible, but discouraged, as it will generate a significant volume of events.

This method instructs the user agent to register the observer and must run these steps:

  1. If options' entryTypes attribute is not present, throw a JavaScript TypeError.
  2. Filter unsupported entryType names within the entryTypes sequence, and replace the entryTypes sequence with the new filtered sequence.
  3. If the options' entryTypes attribute is an empty sequence, throw a JavaScript TypeError.
  4. If the list of registered performance observer objects associated with the ECMAScript global environment of the interface object's contains a registered performance observer that is the context object, replace the context object's options with options.
  5. Otherwise, append a new registered performance observer object to the list of registered performance observer objects associated with the ECMAScript global environment of the interface object, with the context object as observer and options as the options.
ParameterTypeNullableOptionalDescription
optionsPerformanceObserverInit✘✘
Return type: void

3.3.2 The PerformanceObserverEntryList interface

The PerformanceObserverEntryList interface provides the same getEntries, getEntriesByType, getEntriesByName methods as the Performance interface, except that PerformanceObserverEntryList operates on the observed emitted list of events instead of the global timeline.

[Exposed=(Window,Worker)]
interface PerformanceObserverEntryList {
    PerformanceEntryList getEntries (optional PerformanceEntryFilterOptions filter);
    PerformanceEntryList getEntriesByType (DOMString type);
    PerformanceEntryList getEntriesByName (DOMString name, optional DOMString type);
};
3.3.2.1 Methods
getEntries
See performance.getEntries.
ParameterTypeNullableOptionalDescription
filterPerformanceEntryFilterOptions✘✔
getEntriesByName
See performance.getEntriesByName.
ParameterTypeNullableOptionalDescription
nameDOMString✘✘
typeDOMString✘✔
getEntriesByType
See performance.getEntriesByType.
ParameterTypeNullableOptionalDescription
typeDOMString✘✘

A. References

A.1 Normative references

[HR-TIME-2]
Ilya Grigorik; James Simonsen; Jatinder Mann. High Resolution Time Level 2. 28 September 2015. W3C Working Draft. URL: http://www.w3.org/TR/hr-time-2/
[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119
[WebIDL]
Cameron McCormack; Boris Zbarsky. WebIDL Level 1. 4 August 2015. W3C Working Draft. URL: http://www.w3.org/TR/WebIDL-1/

A.2 Informative references

[FRAME-TIMING]
Michael Blain; Ilya Grigorik. Frame Timing. 8 October 2015. W3C Working Draft. URL: http://www.w3.org/TR/frame-timing/
[NAVIGATION-TIMING-2]
Tobin Titus; Jatinder Mann; Arvind Jain. Navigation Timing Level 2. 25 September 2015. W3C Working Draft. URL: http://www.w3.org/TR/navigation-timing-2/
[RESOURCE-TIMING]
Arvind Jain; Todd Reifsteck; Jatinder Mann; Zhiheng Wang; Anderson Quach. Resource Timing. 20 October 2015. W3C Working Draft. URL: http://www.w3.org/TR/resource-timing/
[SERVER-TIMING]
Ilya Grigorik. Server Timing. 17 July 2015. W3C Working Draft. URL: http://www.w3.org/TR/server-timing/
[USER-TIMING]
Jatinder Mann; Zhiheng Wang; Anderson Quach. User Timing. 12 December 2013. W3C Recommendation. URL: http://www.w3.org/TR/user-timing/