Resources Included in the PerformanceResourceTiming
data-cite="HTML#concept-settings-object-global">global object's
Performance
-Timeline, unless excluded from the timeline as part of the processing model.
+Timeline, unless excluded from the timeline as part of the [=fetch|fetching process=].
Resources that are retrieved from
relevant
application caches or local resources MUST be included as
@@ -266,14 +270,13 @@
If the same canonical URL is used as the src
-attribute of two HTML IMG elements, the fetch of the resource initiated by the
+attribute of two HTML IMG elements, the [=fetch=] of the resource initiated by the
first HTML IMG element SHOULD be included as a
PerformanceResourceTiming object in the Performance
@@ -286,8 +289,7 @@
If the src attribute of a HTML IMG
-element is changed via script, both the fetch of the original resource as well as
+element is changed via script, both the [=fetch=] of the original resource as well as
the fetch of the new URL
would be included as PerformanceResourceTiming objects in
the Resources Included in the PerformanceResourceTimingIFRAME. If at a later time the src
attribute is changed dynamically via script, the user agent may
fetch the new URL resource
-for the IFRAME. In this case, only the fetch of the new URL would be included as
+for the IFRAME. In this case, only the [=fetch=] of the new URL would be included as
a PerformanceResourceTiming object in the Performance
Timeline.
@@ -309,8 +310,7 @@
Resources Included in the PerformanceResourceTiming
"FETCH#concept-fetch">fetches of the resource would be included
as a PerformanceResourceTiming object in the Performance
-Timeline. This is because the fetch of the resource for the second
+Timeline. This is because the [=fetch=] of the resource for the second
XMLHttpRequest cannot reuse the download issued for
the first XMLHttpRequest.
If an HTML IFRAME element is included on the page,
@@ -332,8 +332,7 @@
Resources Included in the PerformanceResourceTiming
"PERFORMANCE-TIMELINE-2#performance-timeline">Performance
Timeline. By definition data: URI contains
-embedded data and does not require a fetch.
+embedded data and does not require a [=fetch=].
If a resource fetch was
aborted due to a networking error (e.g. DNS, TCP, or TLS error),
then the fetch MAY be included as a
@@ -354,40 +353,6 @@
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 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.
-
-
- DOMHighResTimeStamp is defined in [[HR-TIME-2]].
-
"xmlhttprequest", if the request is a result of
-processing an XMLHttpRequest object [[XHR]];
-
"fetch", if the request is the result of processing
-the Fetch method
-[[FETCH]];
-
"beacon", if the request is the result of processing
-the sendBeacon
-method [[BEACON]];
-
"other", if none of the above conditions match.
-
-
On getting, the
-attribute nextHopProtocol returns the network protocol
-used to fetch the resource, as identified by the ALPN Protocol ID
-[[RFC7301]]; resources retrieved from relevant application caches
-or local resources, return an empty string. 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.
-
Formally registered ALPN protocol IDs are documented by
-IANA. In case the user agent is using an experimental,
-non-registered protocol, the user agent MUST use the ALPN
-negotiated value if any. If ALPN was not used for protocol
-negotiations, the user agent MAY use another descriptive
-string.
-
The "h3" ALPN ID is defined for the final version
-of the HTTP/3 protocol in the HTTP/3 Internet Draft.
-
Note that the nextHopProtocol 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.
-
On getting, the
-workerStart attribute MUST return as follows:
the time immediately before the user agent runs the worker
-required to service the request.
-
-
-
zero, otherwise.
-
-
Note that according to the definition of time origin in workers, it is
-possible that some attributes of
-navigation preload requests will have negative {{DOMHighResTimeStamp}}
-values.
-
On getting, the
-redirectStart attribute MUST return as follows:
-
-
The time immediately before the user agent starts to
-fetch the resource that
-initiates the redirect, if there are HTTP redirects or
-equivalent when fetching the resource and
-the resource passes the timing allow check algorithm.
-
zero, otherwise.
-
-
On getting, the
-redirectEnd attribute MUST return as follows:
-
-
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
-the resource passes the timing allow check algorithm.
-
zero, otherwise.
-
-
On getting, the
-fetchStart attribute MUST return as follows:
-
-
The time immediately before the user agent starts to
-fetch the final
-resource in the redirection, if there are HTTP redirects or
-equivalent.
-
The time immediately before the user agent starts to
-fetch the resource
-otherwise.
-
-
On getting, the
-domainLookupStart attribute MUST return as follows:
The time immediately after the user agent starts the domain
-data retrieval from the domain information cache, if the user agent
-has the domain information in cache.
-
The time immediately before the user agent starts the domain
-name lookup for the resource, otherwise.
-
-
On getting, the
-domainLookupEnd attribute MUST return as follows:
The time immediately after the user agent ends the domain data
-retrieval from the domain information cache, if the user agent has
-the domain information in cache.
-
The time immediately after the user agent finishes the domain
-name lookup for the resource, otherwise.
-
-
On getting, the
-connectStart attribute MUST return as follows:
The returned time MUST include the time interval to establish the transport
- connection, as well as other time intervals such as SOCKS authentication. It
- MUST include the time interval to complete enough of the TLS handshake to
- request the resource.
-
If the user agent used TLS False Start [[RFC7918]] for this connection,
- this interval MUST NOT include the time needed to receive the server's
- Finished message.
-
If the user agent sends the request with early data [[RFC8470]] without
- waiting for the full handshare to complete, this interval MUST NOT include
- the time needed to receive the server's ServerHello message.
-
If the user agent waits for full handshake completion to send the
- request, this interval includes the full TLS handshake even if other
- requests were sent using early data on this connection.
-
-
-
Example: Suppose the user agent establishes an HTTP/2 connection
-over TLS 1.3 to send a GET request and a POST request. It sends the ClientHello
-at time t1 and then sends the GET request with early data. The
-POST request is not safe [[RFC7231]] (section 4.2.1), so the user agent waits
-to complete the handshake at time t2 before sending it. Although
-both requests used the same connection, the GET request reports a connectEnd
-value of t1, while the POST request reports a connectEnd value for
-t2.
The time immediately before the user agent starts the handshake
-process to secure the current connection, otherwise.
-
-
On getting, the
-requestStart attribute MUST return as follows:
-
-
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 resource passes the timing allow
-check algorithm.
-
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.
-
-
zero, otherwise.
-
-
-
On getting, the
-responseStart attribute MUST return as follows:
-
-
The time immediately after the user agent's HTTP parser
-receives the first byte of the response (e.g. frame header bytes
-for HTTP/2, or response status line for HTTP/1.x) from
-relevant application
-caches, or from local resources or from the server, if the
-resource passes the timing allow check algorithm.
-
zero, otherwise.
-
-
-
On getting, the
-responseEnd attribute MUST return the result of running
-the algorithm to get response end time.
The duration getter steps are to return
+this's timing info's
+[=fetch timing info/end time=] minus this's timing
+info's [=fetch timing info/start time=].
+
-
When requested to run the get response end time
-algorithm, the user agent must run the following steps:
-
-
If the fetch was aborted due to a network error, return the time
-immediately before the user agent aborts the fetch.
-
Otherwise, return the time immediately after the user agent
-receives the last byte of the response or immediately before the
-transport connection is closed, whichever comes first. The resource
-here can be received either from relevant application
-caches, local resources, or from the server.
-
-
On getting, the
-transferSize attribute MUST return as follows:
-
-
the size, in octets received from a HTTP-network fetch, consumed by the
-response header fields and the response payload body [[RFC7230]], if the
-resource passes the timing allow check algorithm.
-
If there are HTTP redirects or equivalent when
-navigating and if all the redirects or equivalent are same origin, this attribute SHOULD
-include the HTTP overhead of incurred redirects.
-
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 [[RFC5246]]or TCP).
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.
-
-
Timing-Allow-Origin Response Header
-
The Timing-Allow-Origin HTTP response header field
-can be used to communicate a policy indicating origin(s) that are
-allowed to see values of attributes that would have been zero due
-to the cross-origin restrictions. The header's value is represented
-by the following ABNF [[RFC5234]] (using List Extension, [[RFC7230]]):
The sender MAY generate multiple Timing-Allow-Origin
-header fields. The recipient MAY combine multiple
-Timing-Allow-Origin header fields by appending each
-subsequent field value to the combined field value in order,
-separated by a comma.
-
The timing allow check algorithm, which checks
-whether a resource's timing information can be shared with the
-current document, is as follows:
The Timing-Allow-Origin header may arrive as part of a cached
-response. In case of cache revalidation, according to
-RFC 7234,
-the header's value may come from the revalidation response, or if not present
-there, from the original cached resource.
+
Cross-origin Resources
+
As detailed in [=Fetch=],
+ cross-origin resources are included as PerformanceResourceTiming objects in the
+ Performance
+ Timeline. If the timing allow check algorithm
+ fails for a resource, the following attributes of its PerformanceResourceTiming
+ object are set to zero:
+{{PerformanceResourceTiming/redirectStart}}, {{PerformanceResourceTiming/redirectEnd}},
+{{PerformanceResourceTiming/domainLookupStart}}, {{PerformanceResourceTiming/domainLookupEnd}},
+{{PerformanceResourceTiming/connectStart}}, {{PerformanceResourceTiming/connectEnd}},
+{{PerformanceResourceTiming/requestStart}}, {{PerformanceResourceTiming/responseStart}},
+{{PerformanceResourceTiming/secureConnectionStart}}, {{PerformanceResourceTiming/transferSize}},
+{{PerformanceResourceTiming/encodedBodySize}}, and {{PerformanceResourceTiming/decodedBodySize}}.
+
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.
+
+
Timing-Allow-Origin Response Header
+
The Timing-Allow-Origin HTTP response header field
+ can be used to communicate a policy indicating origin(s) that are
+ allowed to see values of attributes that would have been zero due
+ to the cross-origin restrictions. The header's value is represented
+ by the following ABNF [[RFC5234]] (using List Extension, [[RFC7230]]):
The sender MAY generate multiple Timing-Allow-Origin
+ header fields. The recipient MAY combine multiple
+ Timing-Allow-Origin header fields by appending each
+ subsequent field value to the combined field value in order,
+ separated by a comma.
+
The Timing-Allow-Origin headers are processed in
+ FETCH to compute the attributes accordingly.
+
The Timing-Allow-Origin header may arrive as part of a cached
+ response. In case of cache revalidation, according to
+ RFC 7234,
+ the header's value may come from the revalidation response, or if not present
+ there, from the original cached resource.
IANA Considerations
@@ -1010,227 +697,49 @@
IANA Considerations
Specification document:
-
-
-
Process
-
-
Processing Model
+
+
Resource Timing Attributes
+
This section is non-normative.
The following graph illustrates the timing attributes defined by
-the PerformanceResourceTiming interface. Attributes in parenthesis
-may not be available when fetchingcross-origin resources. User agents may
-perform internal processing in between timings, which allow for non-normative
-intervals between timings.
-
-This figure illustrates the timing attributes defined
-by the PerformanceResourceTiming interface. Attributes in
-parenthesis indicate that they may not be available if the resource
-fails the timing allow check algorithm.
-
-
-
-
For each resource whose Request has a non-null client, perform
-the following steps:
-
-
If the resource is fetched by a
-cross-origin stylesheet which was fetched with no-cors policy,
-abort the remaining steps.
-
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.
-
The above resource exclusion is at risk as currently only one
-implementation passes the related test.
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.
-
Record the initiator of the resource in
-initiatorType.
If no domain lookup is required, go to the step labeled connect start. Otherwise, immediately
-before a user agent starts the domain name lookup, record the time as
-domainLookupStart.
-
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 name lookup fails and
-resource passes the timing allow check record the time as
-domainLookupEnd and go to the step labeledfinal record.
-
Connect start: 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 a successful
-connection to the server and record the time as connectEnd
-immediately after the successful connection to the server or proxy is
-established. A user agent may need multiple retries to establish a
-successful connection and should reflect the timestamps for the
-successful connection only.
-Once connection is established set the value of nextHopProtocol
-to the ALPN ID used by the connection. If a connection can not be
-established, record the time up to the connection failure as
-connectEnd and go to the step labeled final record.
When a secure transport is used, the user agent MUST record the
-time as secureConnectionStart immediately before the
-handshake process to secure the connection.
-
When a secure transport is not used, the user agent MUST set
-the value of secureConnectionStart to 0.
-
-
-
Request start: Immediately before a user agent starts
-sending the request for the resource, record the
-current time as requestStart. If a user agent needed
-multiple retries to send the request, record the current time
-of the last attempt.
-
Network protocols may not perform the connection
-establishment, secure connection establishment and request sending in a
-sequential manner. Therefore, developers should not expect these values
-to always be in a particular order.
-
-
Record the time as responseStart immediately after the user agent receives the
-first byte of the response.
-
Response end: Record the time as responseEnd immediately after receiving the last byte of
-the response.
-
-
Return to the step labeled connect start if the
-user agent fails to send the request or receive the entire
-response, and needs to reopen the connection.
-
-
If the fetched resource results in an HTTP redirect or
-equivalent, then
+ the PerformanceResourceTiming interface. Attributes in parenthesis
+ may not be available when [=fetch|fetching=] cross-origin resources. User agents may
+ perform internal processing in between timings, which allow for non-normative
+ intervals between timings.
+
+ This figure illustrates the timing attributes defined
+ by the PerformanceResourceTiming interface. Attributes in
+ parenthesis indicate that they may not be available if the resource
+ fails the timing allow check algorithm.
+
+
+
+
+
Creating a resource timing entry
+
To mark resource timing given a
+[=/fetch timing info=] |timingInfo|, a DOMString
+|requestedURL|, a DOMString |initiatorType| and a global object |global|:
This specification does not specify whether steps
-20 and 21 should run before or after the load event of
-the resource—see issue 82 for
-related discussion.
-
-
-
-
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.
-
+
+
To convert fetch timestamp given {{DOMHighResTimeStamp}} |ts| and
+global object |global|, do the following:
+
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 . Resource providers can
+and certain attributes are set to zero, as described in [=/HTTP fetch=]. 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
@@ -1250,8 +758,7 @@
Privacy and Security
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
+for resources in a document, the cross-origin restrictions in in [=/HTTP Fetch=] 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.
