Abstract

This specification defines an interface for web applications to access the complete timing information for resources in a document.

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 a work in progress and may change without any notices.

Please send comments to public-web-perf@w3.org (archived) with [ResourceTiming] at the start of the subject line.

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). 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.

User latency is an important quality benchmark for Web Applications. While JavaScript-based mechanisms can provide comprehensive instrumentation for user latency measurements within an application, in many cases, they are unable to provide a complete end-to-end latency picture. While Navigation Timing 2 [NAVIGATION-TIMING-2] addresses part of the problem by providing timing information associated with a navigation, this document introduces the PerformanceResourceTiming interface to allow JavaScript mechanisms to collect complete timing information related to resources on a document.

For example, the following JavaScript shows a simple attempt to measure the time it takes to fetch a resource:

Example 1
<!doctype html>
<html>
  <head>
  </head>
  <body onload="loadResources()">
    <script>
        function loadResources()
        {
           var start = new Date().getTime();
           var image1 = new Image();
           var resourceTiming = function() {
               var now = new Date().getTime();
               var latency = now - start;
               alert("End to end resource fetch: " + latency);
           };

           image1.onload = resourceTiming;
           image1.src = 'http://www.w3.org/Icons/w3c_main.png';
        }
    </script>
    <img src="http://www.w3.org/Icons/w3c_home.png">
  </body>
</html>

Though this script can measure the time it takes to fetch a resource, it cannot break down the time spent in various phases. Further, the script cannot easily measure the time it takes to fetch resources described in markup.

To address the need for complete information on user experience, this document introduces the PerformanceResourceTiming interface. This interface allows JavaScript mechanisms to provide complete client-side latency measurements within applications. With this interface, the previous example can be modified to measure a user's perceived load time of a resource.

The following script calculates the amount of time it takes to fetch every resource in the page, even those defined in markup. This example assumes that this page is hosted on http://www.w3.org. One could further measure the amount of time it takes in every phase of fetching a resource with the PerformanceResourceTiming interface.

Example 2
<!doctype html>
<html>
  <head>
  </head>
  <body onload="loadResources()">
    <script>
       function loadResources()
       {
          var image1 = new Image();
          image1.onload = resourceTiming;
          image1.src = 'http://www.w3.org/Icons/w3c_main.png';
       }

       function resourceTiming()
       {
           var resourceList = window.performance.getEntriesByType("resource");
           for (i = 0; i < resourceList.length; i++)
           {
              if (resourceList[i].initiatorType == "img")
              {
                 alert("End to end resource fetch: "+ resourceList[i].responseEnd - resourceList[i].startTime);
              }
           }
       }
    </script>
    <img id="image0" src="http://www.w3.org/Icons/w3c_home.png">
  </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 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]

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 specification. [DOM]

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 ECMA262, rather than the official term ECMAScript, since the term JavaScript is more widely known. [ECMA-262]

The term resource is used to refer to elements and any other user-initiated fetches throughout this specification. For example, a resource could originate from XMLHttpRequest objects [[XMLHttpRequest], HTML elements [HTML5] such as iframe, img, script, object, embed, and link with the link type of stylesheet, and SVG elements [SVG11] such as svg.

The term cross-origin is used to mean non same origin.

The term current document refers to the document associated with the Window object's newest Document object.

Throughout this work, all time values are measured in milliseconds since the start of navigation of the document [HR-TIME-2]. 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.

Note

This definition of time is based on the High Resolution Time specification [HR-TIME-2] and is different from the definition of time used in the Navigation Timing specification [NAVIGATION-TIMING], where time is measured in milliseconds since midnight of January 1, 1970 (UTC).

4. Resource Timing

4.1 Introduction

This section is non-normative.

The PerformanceResourceTiming interface facilitates timing measurement of downloadable resources. For example, this interface is available for XMLHttpRequest objects [XMLHttpRequest], HTML elements [HTML5] such as iframe, img, script, object, embed, and link with the link type of stylesheet, and SVG elements [SVG11] such as svg.

4.2 Resources Included in the PerformanceResourceTiming Interface

All resources fetched by the current browsing [HTML5] or worker [WORKERS] context's MUST be included as PerformanceResourceTiming objects in the Performance Timeline of the relevant context. Resources that are retrieved from relevant application caches or local resources MUST be included as PerformanceResourceTiming objects in the Performance Timeline ([PERFORMANCE-TIMELINE-2]). Resources for which the fetch was initiated, but was later aborted (e.g. due to a network error) MUST be included as PerformanceResourceTiming objects in the Performance Timeline and MUST contain initialized attribute values for processed substeps of the processing model.

The rest of this section is non-normative.

Examples:

The user agent MAY choose to limit how many resources are included as PerformanceResourceTiming objects in the Performance Timeline. The recommended minimum number of PerformanceResourceTiming objects is 150, though this may be changed by the user agent. setResourceTimingBufferSize can be called to request a change to this limit.

4.3 The PerformanceResourceTiming Interface

The PerformanceResourceTiming interface participates in the Performance Timeline and extends the following attributes of the PerformanceEntry interface:

name
This attribute MUST return the resolved URL of the requested resource. This attribute MUST NOT change even if the fetch redirected to a different URL.
entryType
The entryType attribute MUST return the DOMString "resource".
startTime
The startTime attribute MUST return a DOMHighResTimeStamp [HR-TIME-2] with the time immediately before the user agent starts to queue the resource for fetching. If there are HTTP redirects or equivalent when fetching the resource, and if all the redirects or equivalent are from the same origin as the current document or the timing allow check algorithm passes, this attribute MUST return the same value as redirectStart. Otherwise, this attribute MUST return the same value as fetchStart.
duration
The duration attribute MUST return a DOMHighResTimeStamp equal to the difference between responseEnd and startTime, respectively.
[Exposed=(Window,Worker)]
interface PerformanceResourceTiming : PerformanceEntry {
    readonly    attribute DOMString           initiatorType;
    readonly    attribute DOMString           nextHopProtocol;
    readonly    attribute DOMHighResTimeStamp workerStart;
    readonly    attribute DOMHighResTimeStamp redirectStart;
    readonly    attribute DOMHighResTimeStamp redirectEnd;
    readonly    attribute DOMHighResTimeStamp fetchStart;
    readonly    attribute DOMHighResTimeStamp domainLookupStart;
    readonly    attribute DOMHighResTimeStamp domainLookupEnd;
    readonly    attribute DOMHighResTimeStamp connectStart;
    readonly    attribute DOMHighResTimeStamp connectEnd;
    readonly    attribute DOMHighResTimeStamp secureConnectionStart;
    readonly    attribute DOMHighResTimeStamp requestStart;
    readonly    attribute DOMHighResTimeStamp responseStart;
    readonly    attribute DOMHighResTimeStamp responseEnd;
    readonly    attribute unsigned long long  transferSize;
    readonly    attribute unsigned long long  encodedBodySize;
    readonly    attribute unsigned long long  decodedBodySize;
    serializer = {inherit, attribute};
};

4.3.1 Attributes

connectEnd of type DOMHighResTimeStamp, readonly

This attribute MUST return the time immediately after the user agent finishes establishing the connection to the server to retrieve the resource. If a persistent connection [RFC7230] is used or the resource is retrieved from relevant application caches or local resources, this attribute MUST return the value of domainLookupEnd.

If the transport connection fails and the user agent reopens a connection, connectStart and connectEnd SHOULD return the corresponding values of the new connection.

connectEnd MUST include the time interval to establish the transport connection, as well as other time intervals such as SSL handshake and SOCKS authentication.

If the last non-redirected fetch of the resource is not the same origin as the current document, connectEnd MUST return zero unless the timing allow check algorithm passes.

connectStart of type DOMHighResTimeStamp, readonly

This attribute MUST return the time immediately before the user agent start establishing the connection to the server to retrieve the resource. If a persistent connection [RFC7230] is used or the resource is retrieved from relevant application caches or local resources, this attribute MUST return value of domainLookupEnd.

If the last non-redirected fetch of the resource is not the same origin as the current document, connectStart MUST return zero unless timing allow check algorithm passes.

decodedBodySize of type unsigned long long, readonly

This attribute MUST return the size, in octets received from a HTTP-network-or-cache fetch, of the message body [RFC7230], after removing any applied content-codings [RFC7231]:

domainLookupEnd of type DOMHighResTimeStamp, readonly

This attribute MUST return the time immediately after the user agent finishes the domain name lookup for the resource. If a persistent connection [RFC7230] is used or the resource is retrieved from relevant application caches or local resources, this attribute MUST return the same value as fetchStart.

If the user agent has the domain information in cache, domainLookupStart and domainLookupEnd represent the times when the user agent starts and ends the domain data retrieval from the cache.

If the last non-redirected fetch of the resource is not the same origin as the current document, domainLookupEnd MUST return zero unless the timing allow check algorithm passes.

domainLookupStart of type DOMHighResTimeStamp, readonly

This attribute MUST return the time immediately before the user agent starts the domain name lookup for the resource. If a persistent connection [RFC7230] is used or the resource is retrieved from relevant application caches or local resources, this attribute MUST return the same value as fetchStart.

If the last non-redirected fetch of the resource is not the same origin as the current document, domainLookupStart MUST return zero unless the timing allow check algorithm passes.

encodedBodySize of type unsigned long long, readonly

This attribute MUST return the size, in octets received from a HTTP-network-or-cache fetch, of the payload body [RFC7230], prior to removing any applied content-codings [RFC7231]:

Note

The encodedBodySize may be zero depending on the response code - e.g. HTTP 204 (No Content), 3XX, etc.

fetchStart of type DOMHighResTimeStamp, readonly

If there are no HTTP redirects or equivalent, this attribute MUST return the time immediately before the user agent starts to fetch the resource.

If there are HTTP redirects or equivalent, this attribute MUST return the time immediately before the user agent starts to fetch the final resource in the redirection.

initiatorType of type DOMString, readonly

If the initiator is an element, on getting, the initiatorType attribute MUST return a DOMString with the same value as the localName of that element [DOM].

If the initiator is a CSS resource downloaded by the url() syntax [CSS-SYNTAX-3], such as @import url() or background: url(), on getting, the initiatorType attribute MUST return the DOMString "css".

If the initiator is an XMLHttpRequest object [XMLHttpRequest], on getting, the initiatorType attribute MUST return the DOMString "xmlhttprequest".

nextHopProtocol of type DOMString, readonly

This attribute MUST return the network protocol used to fetch the resource, as identified by the ALPN Protocol ID [RFC7301]. When a proxy is configured, if a tunnel connection is established then this attribute MUST return the ALPN Protocol ID of the tunneled protocol, otherwise it MUST return the ALPN Protocol ID of the first hop to the proxy.

In order to have precisely one way to represent any ALPN protocol ID, the following additional constraints apply: octets in the ALPN protocol MUST NOT be percent-encoded if they are valid token characters except "%", and when using percent-encoding, uppercase hex digits MUST be used.

Note that this attribute is intended to identify the network protocol in use for the fetch regardless of how it was actually negotiated; that is, even if ALPN is not used to negotiate the network protocol, this attribute still uses the ALPN Protocol ID's to indicate the protocol in use.

redirectEnd of type DOMHighResTimeStamp, readonly

If there are HTTP redirects or equivalent when fetching the resource and if all the redirects or equivalent are from the same origin as the current document, this attribute MUST return the time immediately after receiving the last byte of the response of the last redirect.

If there are HTTP redirects or equivalent when fetching the resource and if any of the redirects are not from the same origin as the current document, but the timing allow check algorithm passes for each redirected resource, this attribute MUST return the time immediately after receiving the last byte of the response of the last redirect. Otherwise, this attribute MUST return zero.

redirectStart of type DOMHighResTimeStamp, readonly

If there are HTTP redirects or equivalent when fetching the resource and if all the redirects or equivalent are from the same origin as the current document, this attribute MUST return the starting time of the fetch that initiates the redirect.

If there are HTTP redirects or equivalent when fetching the resource and if any of the redirects are not from the same origin as the current document, but the timing allow check algorithm passes for each redirected resource, this attribute MUST return the starting time of the fetch that initiates the redirect. Otherwise, this attribute MUST return zero.

requestStart of type DOMHighResTimeStamp, readonly

This attribute MUST return the time immediately before the user agent starts requesting the resource from the server, or from relevant application caches or from local resources.

If the transport connection fails after a request is sent and the user agent reopens a connection and resend the request, requestStart MUST return the corresponding values of the new request.

If the last non-redirected fetch of the resource is not the same origin as the current document, requestStart MUST return zero unless the timing allow check algorithm passes.

Note

This interface does not include an attribute to represent the completion of sending the request, e.g., requestEnd.

  • Completion of sending the request from the user agent does not always indicate the corresponding completion time in the network transport, which brings most of the benefit of having such an attribute.
  • Some user agents have high cost to determine the actual completion time of sending the request due to the HTTP layer encapsulation.
responseEnd of type DOMHighResTimeStamp, readonly

This attribute MUST return the time immediately after the user agent receives the last byte of the resource or immediately before the transport connection is closed, whichever comes first. The resource here can be received either from the server, relevant application caches or from local resources.

responseStart of type DOMHighResTimeStamp, readonly

This attribute MUST return the time immediately after the user agent receives the first byte of the response from the server, or from relevant application caches or from local resources.

If the last non-redirected fetch of the resource is not the same origin as the current document, responseStart MUST return zero unless the timing allow check algorithm passes.

secureConnectionStart of type DOMHighResTimeStamp, readonly

When a secure transport is used, this attribute MUST return the time immediately before the user agent starts the handshake process to secure the current connection. If a secure transport is not used, this attribute MUST return zero. If a persistent connection [RFC7230] is used or the resource is retrieved from relevant application caches or local resources, this attribute MUST return value of domainLookupEnd.

If the last non-redirected fetch of the resource is not the same origin as the current document, secureConnectionStart MUST return zero unless the timing allow check algorithm passes.

transferSize of type unsigned long long, readonly

This attribute MUST return the size, in octets received from a HTTP-network fetch, consumed by the response header fields and the response payload body [RFC7230]:

This attribute SHOULD include HTTP overhead (such as HTTP/1.1 chunked encoding and whitespace around header fields, including newlines, and HTTP/2 frame overhead, along with other server-to-client frames on the same stream), but SHOULD NOT include lower-layer protocol overhead (such as TLS or TCP).

Note

It is possible for transferSize value to be lower than encodedBodySize: when a cached response is successfully revalidated the transferSize reports the size of the response HTTP headers incurred during the revalidation, and encodedBodySize reports the size of the previously retrieved payload body.

workerStart of type DOMHighResTimeStamp, readonly
If the current browsing or worker context's have an active worker ([SERVICE-WORKERS]), this attribute MUST return the time immediately before the user agent runs the worker required to service the request, or if the worker is available, the time immediately before the user agent fires an event named `fetch` at the active worker. Otherwise, if there is no active worker this attribute MUST return zero.

4.3.2 Serializer

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

4.4 Extensions to the Performance Interface

partial interface Performance {
    void clearResourceTimings();
    void setResourceTimingBufferSize(unsigned long maxSize);
                attribute EventHandler onresourcetimingbufferfull;
};

The method clearResourceTimings clears the buffer used to store the current list of PerformanceResourceTiming resources.

The setResourceTimingBufferSize method, when invoked, MUST set the maximum number of PerformanceResourceTiming resources that may be stored in the buffer to the value of the maxSize parameter. The buffer is considered to be full if the number of entries in it is greater than or equal to maxSize.

If this method is not called, the user agent SHOULD store at least 150 PerformanceResourceTiming resources in the buffer, unless otherwise specified by the user agent.

If the maxSize parameter is less than the number of elements currently stored in the buffer, no elements in the buffer are to be removed and the user agent MUST NOT fire the resourcetimingbufferfull event.

The attribute onresourcetimingbufferfull is the event handler for the resourcetimingbufferfull event. Immediately after the buffer used to store the list of PerformanceResourceTiming resources becomes full, the User Agent MUST fire a simple event named resourcetimingbufferfull that bubbles, isn't cancelable, has no default action, at the Performance object.

4.5 Cross-origin Resources

Cross-origin resources MUST be included as PerformanceResourceTiming objects in the Performance Timeline. If the timing allow check algorithm fails for a cross-origin resource, these attributes of its PerformanceResourceTiming object MUST be set to zero: redirectStart, redirectEnd, domainLookupStart, domainLookupEnd, connectStart, connectEnd, requestStart, responseStart and secureConnectionStart.

Server-side applications may return the Timing-Allow-Origin HTTP response header to allow the User Agent to fully expose, to the document origin(s) specified, the values of attributes that would have been zero due to the cross-origin restrictions previously specified in this section.

4.5.1 Timing-Allow-Origin Response Header

Timing-Allow-Origin

The header indicates whether a resource's timing can be shared based by returning the value of the Origin request header in the response.

ABNF:

Timing-Allow-Origin = "Timing-Allow-Origin" ":" origin-list-or-null | "*"

The timing allow check algorithm, which checks whether a resource's timing information can be shared with the current document, is as follows:

  1. If the resource is not cross-origin, return pass.

  2. If the HTTP response includes zero or more than one Timing-Allow-Origin header values, return fail and terminate this algorithm.

  3. If the Timing-Allow-Origin header value is the "*" character, return pass and terminate this algorithm.

  4. If the value of Timing-Allow-Origin is not a case-sensitive match for the value of the origin of the current document, return fail and terminate this algorithm.

  5. Return pass.

Note

The above algorithm also functions when the ASCII serialization of an origin is the string "null". Typically, this is the case when there are multiple redirects and the initiator is an XMLHttpRequest object.

Note

In practice the origin-list-or-null production is more constrained. Rather than allowing a space-separated list of origins, it is either a single origin or the string "null".

5. Process

5.1 Processing Model

The following graph illustrates the timing attributes defined by the PerformanceResourceTiming interface. Attributes underlined may not be available when fetching resources from different origins. User agents may perform internal processing in between timings, which allow for non-normative intervals between timings.

Resource Timing attributes

  1. Once the Worker or Window object is created, the user agent MUST create a PerformanceEntryList primary buffer object to store the list of PerformanceResourceTiming resources.
  2. Set the primary buffer to a size of 150, unless otherwise specified by the user agent or set by the setResourceTimingBufferSize method.
  3. For each resource fetched by the current browsing context, excluding resources fetched by cross-origin stylesheets fetched with no-cors policy, perform the following steps:
    Issue 1

    Above cross-origin exclusion should be defined via Fetch registry: CSS needs to be defined in terms of Fetch and set some kind of "opaque request flag" for no-CORS CSS subresources. In turn, Resource Timing should interface with Fetch registry to surface resource fetch events.

    1. Create a new PerformanceResourceTiming object and set entryType to the DOMString resource.
    2. Immediately before the user agent starts to queue the resource for retrieval, record the current time in startTime, and set nextHopProtocol to the empty DOMString.
    3. Record the initiator of the resource in initiatorType.
    4. Record the resolved URL of the requested resource in name. If there is an active worker ([SERVICE-WORKERS]) matching the current browsing or worker context's, immediately before the user agent runs the worker record the time as workerStart, or if the worker is already available, immediately before the event named `fetch` is fired at the active worker record the time as workerStart. Otherwise, if there is no matching service worker registration, set workerStart value to zero.
    5. Immediately before a user agent starts the fetching process, record the current time as fetchStart. Let domainLookupStart, domainLookupEnd, connectStart and connectEnd be the same value as fetchStart.
    6. If the user agent is to reuse the data from another existing or completed fetch initiated from the current document, abort the remaining steps.
    7. If fetching the resource is aborted for any reason, abort the remaining steps.
    8. If the last non-redirected fetch of the resource is not the same origin as the current document and the timing allow check algorithm fails, the user agent MUST set redirectStart, redirectEnd, domainLookupStart, domainLookupEnd, connectStart, connectEnd, requestStart, responseStart and secureConnectionStart to zero and go to step 3.17.
    9. Let domainLookupStart, domainLookupEnd, connectStart and connectEnd be the same value as fetchStart.
    10. If the resource is fetched from the relevant application cache or local resources, including the HTTP cache [RFC7234], go to step 3.15.
    11. If no domain lookup is required, go to step 3.13. Otherwise, immediately before a user agent starts the domain name lookup, record the time as domainLookupStart.
    12. Record the time as domainLookupEnd immediately after the domain name lookup is successfully done. A user agent may need multiple retries before that. If the domain lookup fails, abort the remaining steps.
    13. If a persistent transport connection is used to fetch the resource, let connectStart and connectEnd be the same value of domainLookupEnd. Otherwise, record the time as connectStart immediately before initiating the connection to the server and record the time as connectEnd immediately after the connection to the server or the proxy is established. A user agent may need multiple retries before this time. Once connection is established set the value of nextHopProtocol to the ALPN ID used by the connection. If a connection can not be established, abort the remaining steps.
    14. The user agent MUST set the secureConnectionStart attribute as follows:
      1. When a secure transport is used, the user agent MUST record the time as secureConnectionStart immediately before the handshake process to secure the connection.
      2. When a secure transport is not used, the user agent MUST set the value of secureConnectionStart to 0.
    15. Immediately before a user agent starts sending the request for the resource, record the current time as requestStart.
    16. Record the time as responseStart immediately after the user agent receives the first byte of the response.
    17. Record the time as responseEnd immediately after receiving the last byte of the response.
      1. Return to step 3.13 if the user agent fails to send the request or receive the entire response, and needs to reopen the connection.
        EXAMPLE

        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.

      2. Set the value of transferSize, encodedBodySize, decodedBodySize to corresponding values, subject to timing allow check algorithm.
    18. Record the difference between responseEnd and startTime in duration.
    19. If the fetched resource results in an HTTP redirect or equivalent, then
      1. If the current resource and the redirected resource are not from the same origin as the current document, and the timing allow check algorithm fails for either resource, set redirectStart and redirectEnd to 0. Then, return to step 3.5 with the new resource.
      2. If the value of redirectStart is not set, let it be the value of fetchStart.
      3. Let redirectEnd be the value of responseEnd.
      4. Set all the attributes in the PerformanceResourceTiming object to 0 except startTime, redirectStart, redirectEnd, and initiatorType.
      5. Return to step 3.5 with the new resource.
    20. Queue the PerformanceResourceTiming object.
    21. If the primary buffer is not full, add the PerformanceResourceTiming object to the primary buffer. If adding it causes the primary buffer to become full, fire the resourcetimingbufferfull event at the Document.
      1. If the clearResourceTimings method is called in the event handler for the resourcetimingbufferfull event, clear all PerformanceResourceTiming objects in the primary buffer.
      2. If the setResourceTimingBufferSize method is called in the event handler for the resourcetimingbufferfull event, set the maximum size of the primary buffer to the maxSize parameter. If the maxSize parameter is less than the number of elements currently stored in the buffer, no elements in the buffer are to be removed.

5.2 Monotonic Clock

The value of the timing attributes MUST monotonically increase to ensure timing attributes are not skewed by adjustments to the system clock while fetching the resource. The difference between any two chronologically recorded timing attributes MUST never be negative. For all resources, including subdocument resources, the user agent MUST record the system clock at the beginning of the root document navigation and define subsequent timing attributes in terms of a monotonic clock measuring time elapsed from the beginning of the navigation.

6. Privacy and Security

This section is non-normative.

The PerformanceResourceTiming interface exposes timing information for a resource to any web page or worker that has requested that resource. To limit the access to the PerformanceResourceTiming interface, the same origin policy is enforced by default and certain attributes are set to zero, as described in 4.5 Cross-origin Resources. Resource providers can explicitly allow all timing information to be collected for a resource by adding the Timing-Allow-Origin HTTP response header, which specifies the domains that are allowed to access the timing information.

Statistical fingerprinting is a privacy concern where a malicious web site may determine whether a user has visited a third-party web site by measuring the timing of cache hits and misses of resources in the third-party web site. Though the PerformanceResourceTiming interface gives timing information for resources in a document, the cross-origin restrictions prevent making this privacy concern any worse than it is today using the load event on resources to measure timing to determine cache hits and misses.

A. Acknowledgments

We would like to sincerely thank Karen Anderson, Darin Fisher, Tony Gentilcore, Nic Jansma, Kyle Scholz, Jonas Sicking, James Simonsen, Steve Souders, Annie Sullivan, Sigbjørn Vik, Jason Weber to acknowledge their contributions to this work.

B. References

B.1 Normative references

[CSS-SYNTAX-3]
Tab Atkins Jr.; Simon Sapin. CSS Syntax Module Level 3. 20 February 2014. W3C Candidate Recommendation. URL: http://www.w3.org/TR/css-syntax-3/
[DOM]
Anne van Kesteren; Aryeh Gregor; Ms2ger; Alex Russell; Robin Berjon. W3C DOM4. 6 October 2015. W3C Proposed Recommendation. URL: http://www.w3.org/TR/dom/
[HR-TIME-2]
Ilya Grigorik; James Simonsen; Jatinder Mann. High Resolution Time Level 2. 21 October 2015. W3C Working Draft. URL: http://www.w3.org/TR/hr-time-2/
[HTML5]
Ian Hickson; Robin Berjon; Steve Faulkner; Travis Leithead; Erika Doyle Navara; Edward O'Connor; Silvia Pfeiffer. HTML5. 28 October 2014. W3C Recommendation. URL: http://www.w3.org/TR/html5/
[PERFORMANCE-TIMELINE-2]
Ilya Grigorik. Performance Timeline Level 2. 24 October 2015. W3C Working Draft. URL: http://www.w3.org/TR/performance-timeline-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
[RFC2397]
L. Masinter. The "data" URL scheme. August 1998. Proposed Standard. URL: https://tools.ietf.org/html/rfc2397
[RFC6454]
A. Barth. The Web Origin Concept. December 2011. Proposed Standard. URL: https://tools.ietf.org/html/rfc6454
[RFC7230]
R. Fielding, Ed.; J. Reschke, Ed.. Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing. June 2014. Proposed Standard. URL: https://tools.ietf.org/html/rfc7230
[RFC7231]
R. Fielding, Ed.; J. Reschke, Ed.. Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. June 2014. Proposed Standard. URL: https://tools.ietf.org/html/rfc7231
[RFC7234]
R. Fielding, Ed.; M. Nottingham, Ed.; J. Reschke, Ed.. Hypertext Transfer Protocol (HTTP/1.1): Caching. June 2014. Proposed Standard. URL: https://tools.ietf.org/html/rfc7234
[RFC7301]
S. Friedl; A. Popov; A. Langley; E. Stephan. Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension. July 2014. Proposed Standard. URL: https://tools.ietf.org/html/rfc7301
[SERVICE-WORKERS]
Alex Russell; Jungkee Song; Jake Archibald. Service Workers. 25 June 2015. W3C Working Draft. URL: http://www.w3.org/TR/service-workers/
[WORKERS]
Ian Hickson. Web Workers. 24 September 2015. W3C Working Draft. URL: http://www.w3.org/TR/workers/
[WebIDL]
Cameron McCormack; Boris Zbarsky. WebIDL Level 1. 4 August 2015. W3C Working Draft. URL: http://www.w3.org/TR/WebIDL-1/
[XMLHttpRequest]
Anne van Kesteren; Julian Aubourg; Jungkee Song; Hallvord Steen et al. XMLHttpRequest Level 1. 30 January 2014. W3C Working Draft. URL: http://www.w3.org/TR/XMLHttpRequest/

B.2 Informative references

[ECMA-262]
ECMAScript Language Specification. URL: https://tc39.github.io/ecma262/
[NAVIGATION-TIMING]
Zhiheng Wang. Navigation Timing. 17 December 2012. W3C Recommendation. URL: http://www.w3.org/TR/navigation-timing/
[NAVIGATION-TIMING-2]
Tobin Titus; Jatinder Mann; Arvind Jain. Navigation Timing Level 2. 21 October 2015. W3C Working Draft. URL: http://www.w3.org/TR/navigation-timing-2/
[SVG11]
Erik Dahlström; Patrick Dengler; Anthony Grasso; Chris Lilley; Cameron McCormack; Doug Schepers; Jonathan Watt; Jon Ferraiolo; Jun Fujisawa; Dean Jackson et al. Scalable Vector Graphics (SVG) 1.1 (Second Edition). 16 August 2011. W3C Recommendation. URL: http://www.w3.org/TR/SVG11/