This specification defines an unified interface to store and retrieve performance metric data.
This specification does not cover individual performance metric interfaces.
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 is the second Last Call Working Draft of "Performance Timeline". This new version takes into account the High Resolution Time specification and moves the PerformanceTiming interface to Navigation Timing 2.
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.
Accurately measuring performance characteristics of web applications is an important
aspect of making web applications faster.
Navigation Timing,
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 interfaces, and potentially others created in the future, define performance metrics
that describe the performance timeline of a web application. The
Performance Timeline
specification provides an unifying interface to access and retrieve these various performance metrics from the performance timeline of a
web application.
The following script shows how a developer can use the Performance Timeline interface
to obtain timing data related to the navigation of the document, resources on the page and developer scripts.
<!doctype html>
<html>
<head>
</head>
<body onload="init()">
<img id="image0" src="http://w3c-test.org/webperf/image0.png" />
<script>
function init()
{
performance.mark("startWork");
doWork(); // Some developer code
performance.mark("endWork");
measurePerf();
}
function measurePerf()
{
var perfEntries = performance.getEntries();
for (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>
2 Conformance
requirements
All diagrams, examples, and notes in this specification are non-normative,
as are all sections explicitly marked non-normative. Everything else in this
specification is normative.
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" in the normative parts of this document
are to be interpreted as described in RFC 2119.
For readability, these words do not appear in all uppercase letters in this specification.
Requirements phrased in the imperative as part of algorithms (such as
"strip any leading space characters" or "return false and abort these steps")
are to be interpreted with the meaning of the key word ("must", "should",
"may", etc) used in introducing the algorithm.
Some conformance requirements are phrased as requirements on attributes,
methods or objects. Such requirements are to be interpreted as requirements
on user agents.
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. [Web IDL]
3 Terminology
The construction "a Foo object", where Foo is actually an interface, is sometimes used instead of
the more accurate "an object implementing the interface Foo".
The term DOM is used to refer to the API set made available to scripts in
Web applications, and does not necessarily imply the existence of an actual
Document object or of any other Node objects as
defined in the DOM Core specifications.
A DOM attribute is said to be getting when its value is being
retrieved (such as by author script), and is said to be setting when
a new value is assigned to it.
The term "JavaScript" is used to refer to
ECMA-262,
rather than the official term ECMAScript, since the term JavaScript is more widely known.
The name attribute must return the identifier for this PerformanceEntry object. This
identifier does not have to be unique.
entryType attribute
The entryType attribute must return a DOMString that describes the type of the interface represented by this PerformanceEntry object.
startTime attribute
The startTime attribute must return a DOMHighResTimeStamp
that contains the time value of the first recorded timestamp of this performance metric.
duration attribute
The duration 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. A performance metric may choose
to return a duration of 0, if the duration concept doesn't apply.
The getEntriesByType method returns a
PerformanceEntryList object that contains a copy of all PerformanceEntry objects, in chronological order with respect to startTime,
that have the same value for the entryType attribute of PerformanceEntry as the entryType parameter.
The getEntriesByName method returns a
PerformanceEntryList object that contains a copy of PerformanceEntry objects, in chronological order with respect to startTime,
that have the same value for the name attribute of PerformanceEntry as the name parameter
and, if specified, have the same value for the entryType attribute of PerformanceEntry as the entryType parameter.
Document Object Model Level 3 Core
Specification, A. Le Hors, et al., Editors. World
Wide Web Consortium, 7 April 2004. This version of the Document
Object Model Level 3 Core Recommendation is
http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407. The latest version of
DOM Core is available at
http://www.w3.org/TR/domcore/.
ECMAScript Language Specification, 5.1
Edition. ECMA International, Standard
ECMA-262, June 2011. This version of the ECMAScript
Language is available from http://www.ecma-international.org/publications/standards/Ecma-262.htm.
Navigation Timing, Zhiheng Wang, Editor. World Wide Web Consortium, March 2012. This version of the Navigation Timing specification is available from http://www.w3.org/TR/2012/CR-navigation-timing-20120313/. The latest version of Navigation Timing is available at http://www.w3.org/TR/navigation-timing/.
High Resolution Time, Jatinder Mann, Editor. World Wide Web Consortium, March 2012. This version of the High Resolution Time specification is available from http://www.w3.org/TR/2012/WD-hr-time-20120313/. The latest version of High Resolution Time is available at http://www.w3.org/TR/hr-time/.
Web IDL, Cameron McCormack, Editor. World Wide Web Consortium, April 2012. This version of the Web IDL specification is available from http://www.w3.org/TR/2012/CR-WebIDL-20120419/. The latest version of Web IDL is available at http://www.w3.org/TR/WebIDL/.
Acknowledgements
I would like to offer my sincere thanks to all the people that I have been
in touch with regarding this draft for their reviews and feedback.