Copyright © 2015 W3C® (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and document use rules apply.
This specification defines an interface for web applications to access the complete timing information for navigation of a 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 a work in progress and may change without any notices.
Navigation Timing 2 replaces the first version of [NAVIGATION-TIMING] and includes the following changes:
Implementers SHOULD be aware that this document is not stable. Implementers who are not taking part in the discussions are likely to find the specification changing out from under them in incompatible ways. Vendors interested in implementing this document before it eventually reaches the Candidate Recommendation stage SHOULD join the aforementioned mailing lists and take part in the discussions.
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 [NavigationTiming2] 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 August 2014 W3C Process Document.
This section is non-normative.
Accurately measuring performance characteristics of web applications is an important aspect of making web applications faster. While JavaScript-based mechanisms, such as the one described in [JSMEASURE], can provide comprehensive instrumentation for user latency measurements within an application, in many cases, they are unable to provide a complete or detailed end-to-end latency picture. For example, the following JavaScript shows a naive attempt to measure the time it takes to fully load a page:
<html> <head> <script type="text/javascript"> var start = new Date().getTime(); function onLoad() { var now = new Date().getTime(); var latency = now - start; alert("page loading time: " + latency); } </script> </head> <body onload="onLoad()"> <!- Main page body goes from here. --> </body> </html>
The above script calculates the time it takes to load the page after the first bit of JavaScript in the head is executed, but it does not give any information about the time it takes to get the page from the server, or the initialization lifecycle of the page.
This specification defines the PerformanceNavigationTiming interface which participates in the [PERFORMANCE-TIMELINE] to store and retrieve high resolution performance metric data related to the navigation of a document. As the PerformanceNavigationTiming interface uses [HR-TIME], all time values are measured from the start of the navigation. For example, if we know that the response end occurs 100ms after the start of navigation, we MAY find data that the PerformanceNavigationTiming data looks like so:
startTime: 0.000 // start time of the navigation request responseEnd: 100.000 // high resolution time of last received byte
The following script shows how a developer can use the PerformanceNavigationTiming interface to obtain accurate timing data related to the navigation of the document:
<!doctype html> <html> <head> </head> <body onload="init()"> <script> function init() { var navigationTiming = performance.getEntriesByType("navigation")[0]; if (window.console) { console.log("Name: " + navigationTiming.name + "\n" + "Entry Type: " + navigationTiming.entryType + "\n" + "Start Time: " + navigationTiming.startTime + "\n" + "Duration: " + navigationTiming.duration + "\n" + "Unload: " + (navigationTiming.unloadEventEnd - navigationTiming.unloadEventStart) + "\n" + "Redirect: " + (navigationTiming.redirectEnd - navigationTiming.redirectStart) + "\n" + "App Cache: " + (navigationTiming.domainLookupStart - navigationTiming.fetchStart) + "\n" + "DNS: " + (navigationTiming.domainLookupEnd - navigationTiming.domainLookupStart) + "\n" + "TCP: " + (navigationTiming.connectEnd - navigationTiming.connectStart) + "\n" + "Request: " + (navigationTiming.responseStart - navigationTiming.requestStart) + "\n" + "Response: " + (navigationTiming.responseEnd - navigationTiming.responseStart) + "\n" + "Processing: " + (navigationTiming.loadEventStart - navigationTiming.responseEnd) + "\n" + "Onload: " + (navigationTiming.loadEventEnd - navigationTiming.loadEventStart) + "\n"); } } </script> </body> </html>
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 MAY, MUST, MUST NOT, SHOULD, and SHOULD NOT are to be interpreted as described in [RFC2119].
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. [WebIDL]
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 "navigation" refers to the act of navigating.
The term "JavaScript" is used to refer to ECMA262, rather than the official term ECMAScript, since the term JavaScript is more widely known. [ECMA-262]
Throughout this work, all time values are measured in milliseconds since the start of navigation of the document. For example, the start of navigation of the document occurs at time 0. The term current time refers to the number of milliseconds since the start of navigation of the document until the current moment in time. This definition of time is based on [HR-TIME] specification.
PerformanceNavigationTiming interface. Attributes in parenthesis may not be
available in navigation involving documents from different
origins. User
agents may perform internal processing in between timings, which allow for
non-normative intervals between timings.
PerformanceNavigationTiming object.
DOMString "document".DOMString "navigation".DOMString.DOMString "navigate".DOMString "reload".DOMString "back_forward".When persistent connection [RFC7230] is enabled, a user agent MAY first try to re-use an open connect to send the request while the connection can be asynchronously closed. In such case, connectStart, connectEnd and requestStart SHOULD represent timing information collected over the re-open connection.
prerender to visible. Otherwise, set this attribute to 0.Some user agents maintain the DOM structure of the document in memory
during navigation operations such as forward and backward. In those cases,
the PerformanceNavigationTiming object MUST NOT
be altered during the navigation. Also note that the while the graph above suggests that link negotiation happens before handling a redirect or checking the local caches, in some situations, it MAY happen after those steps. For example, if the current navigation results in a redirect which is present in the local cache, but the target of the redirect is not present in the local cache, the user agent MAY turn on the network interface after processing the redirect and just before it starts to fetch the redirect target from the network.
Vendor-specific proprietary user agent extensions are discouraged. If such extensions are needed, e.g., for experimental purposes, vendors MUST use the following extension mechanisms:
DOMString in the following naming convention: [vendorprefix]_[type], where [vendorprefix] is a name
that identifies the vendor.This section is non-normative.
There is the potential for disclosing an end-user's browsing and activity history by using carefully crafted timing attacks. For instance, the unloading time reveals how long the previous page takes to execute its unload handler, which could be used to infer the user's login status. These attacks have been mitigated by enforcing the same origin policy when timing information involving the previous navigation is accessed.
The relaxed same origin policy doesn't provide sufficient protection against unauthorized visits across documents. In shared hosting, an untrusted third party is able to host an HTTP server at the same IP address but on a different port.
Different pages sharing one host name, for example contents from different authors hosted on sites with user generated content are considered from the same origin because there is no feature to restrict the access by pathname. Navigating between these pages allows a latter page to access timing information of the previous one, such as timing regarding redirection and unload event.
This section is non-normative.
In case a proxy is deployed between the user agent and the web server, the time interval between the connectStart and the connectEnd attributes indicates the delay between the user agent and the proxy instead of the web server. With that, web server can potentially infer the existence of the proxy. For SOCKS proxy, this time interval includes the proxy authentication time and time the proxy takes to connect to the web server, which obfuscate the proxy detection. In case of an HTTP proxy, the user agent might not have any knowledge about the proxy server at all so it's not always feasible to mitigate this attack.
We would like to offer my sincere thanks to James Simonsen, Tony Gentilcore, Zhiheng Wang, Karen Anderson and Jason Weber for all their contributions to this work.