GeezerVison is showing w3c.github.io — Resource Timing
1.
Introduction
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. This document introduces the PerformanceResourceTiming
interface to allow JavaScript mechanisms to collect complete timing
information related to resources on a document. Navigation Timing 2
[NAVIGATION-TIMING-2] extends this specification to provide
additional timing information associated with a navigation.
For example, the following JavaScript shows a simple attempt to measure
the time it takes to fetch a resource:
<!doctype html><html><head></head><bodyonload="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 ='https://www.w3.org/Icons/w3c_main.png';}</script><imgsrc="https://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 https://www.w3.org. One could
further measure the amount of time it takes in every phase of fetching
a resource with the PerformanceResourceTiming interface.
<!doctype html><html><head></head><bodyonload="loadResources()"><script>function loadResources(){var image1 =new Image();
image1.onload = resourceTiming;
image1.src ='https://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><imgid="image0"src="https://www.w3.org/Icons/w3c_home.png"></body></html>
2.
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.
Throughout this work, all time values are measured in milliseconds
since the start of navigation of the document [HR-TIME]. For example,
the start of
navigation of the document occurs at time 0.
This definition of time is based on the High Resolution Time
specification [HR-TIME] and is different from the definition of time
used in the Navigation Timing specification [NAVIGATION-TIMING-2],
where time is measured in milliseconds since midnight of January 1,
1970 (UTC).
If the same canonical URL is used as the src
attribute of two HTML IMG elements, the fetch of the
resource initiated by the first HTML IMG element would
be included as a PerformanceResourceTiming object in the
Performance Timeline. The user agent might not re-request the
URL for the second HTML IMG element, instead using the
existing download it initiated for the first HTML IMG
element. In this case, the fetch of the resource by the first
IMG element would be the only occurrence in the
Performance Timeline.
If the src attribute of a HTML IMG
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 Performance
Timeline.
If an HTML IFRAME element is added via markup
without specifying a src attribute, the user agent may
load the about:blank document for the
IFRAME. 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 a
PerformanceResourceTiming object in the Performance
Timeline.
If an XMLHttpRequest is generated twice for the same
canonical URL, both 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 XMLHttpRequest cannot reuse the download issued
for the first XMLHttpRequest.
If an HTML IFRAME element is included on the page,
then only the resource requested by IFRAMEsrc attribute is included as a
PerformanceResourceTiming object in the Performance
Timeline. Sub-resources requested by the IFRAME
document will be included in the IFRAME document’s
Performance Timeline and not the parent document’s
Performance Timeline.
If a resource fetch was
aborted due to a networking error (e.g. DNS, TCP, or TLS error), then
the fetch will be included as a PerformanceResourceTiming
object in the Performance Timeline with only the startTime,
fetchStart, duration and responseEnd set.
If a resource fetch is
aborted because it failed a fetch precondition (e.g. mixed content,
CORS restriction, CSP policy, etc), then this resource will not be
included as a PerformanceResourceTiming object in the
Performance Timeline.
"body", if the request is a result of processing the
body element’s background attribute that’s
already obsolete.
"css", if the request is a result of processing a
CSS url() directive such as @import
url() or
background: url();
[CSS-VALUES]
Note: the request for a font resource specified with
@font-face in CSS is a result of processing a CSS
directive. Therefore, the initiatorType for this font
resource is "css".
"xmlhttprequest", if the request is a result of
processing an XMLHttpRequest;
"font", if the request is the result of processing
fonts. This can happen when fonts request subsequent resources,
e.g, when Incremental Font Transfer [INCREMENTAL_FONT_TRANSFER] is used.
"fetch", if the request is the result of processing
the fetch() method;
"beacon", if the request is the result of processing
the sendBeacon() method; [BEACON]
"video", if the request is the result of processing
the video element’s poster or src.
"audio", if the request is the result of processing
the audio element’s src.
"track", if the request is the result of processing
the track element’s src.
"img", if the request is the result of processing
the img element’s src or srcset.
"image", if the request is the result of processing
the image
element. [SVG2]
"input", if the request is the result of processing
an input element of typeimage.
"ping", if the request is the result of processing
an a element’s ping.
"iframe", if the request is the result of processing
an iframe’s src.
"frame", if the request is the result of loading a
frame.
"embed", if the request is the result of processing
an embed element’s src.
"link", if the request is the result of processing
an link element.
"object", if the request is the result of processing
an object element.
"early-hints", if the request is the result of
processing an Early Hints [EARLY_HINTS] response.
"other", if none of the above conditions match.
The setting of initiatorType is done at the different places where
a resource timing entry is reported, such as the fetch standard.
"cache", if the cache mode is not the empty
string.
the empty string "", if none of the above
conditions match.
This is expected to be expanded by future updates to this
specification, e.g. to describe consuming preloaded resources and
prefetched navigation requests.
The constant number added to transferSize replaces exposing the
total byte size of the HTTP headers, as that might expose the
presence of certain cookies. See this
issue.
This means that if the resourcetimingbufferfull
event handler does not add more room in the buffer than it adds
resources to it, excess entries will be dropped from the buffer.
Developers need to make sure that
resourcetimingbufferfull event handlers call
clearResourceTimings or extend the buffer
sufficiently (by calling
setResourceTimingBufferSize).
For requests handled by a service worker using
respondWith(), the reported timing data reflects the
interaction between the client and the service worker, rather than
the service worker’s own internal network activity. For example, the
service worker might respond to a same-origin request with a
cross-origin response or vice versa, or return a cached or synthetic
response to either. Given that, resources forwarded from a service
worker do not tell the whole story of fetching the resource, and do
not go through the timing
allow check. To get the full information about those fetches,
the service worker’s own performance timeline can be inspected.
[SERVICE-WORKERS]
For more details, see HTTP Fetch
#4 - the timing
allow check is only performed when there is no response from the
service worker. In addition, the response cloned in the
respondWith() algorithm does not carry the fetch timing info of the internal fetch, as that information is attached
to a fetch rather than to a response.
3.5.2. Timing-Allow-Origin Response Header
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 those cross-origin restrictions.
The Timing-Allow-Origin HTTP response header field can
be used to communicate a policy indicating origin(s) that may be
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, [RFC9110]):
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 user agent MAY still enforce cross-origin restrictions and set
transferSize, encodedBodySize, and decodedBodySize attributes to
zero, even with Timing-Allow-Origin HTTP response header fields. If
it does, it MAY also set deliveryType to "".
The Timing-Allow-Origin header might arrive as part of a cached
response. In case of cache revalidation, according to RFC 7234,
the header’s value might come from the revalidation response, or if
not present there, from the original cached resource.
Issues 222 and
223
suggest to remove wildcard support from Timing-Allow-Origin in
order to restrict its use.
The following graph illustrates the timing attributes defined by the
PerformanceResourceTiming interface. Attributes in parenthesis may
not be available when 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.
4.
Creating a resource timing entry
To mark resource timing given a fetch timing infotimingInfo, a DOMString requestedURL, a DOMString
initiatorType a global objectglobal, a string
cacheMode, a response body infobodyInfo, a
statusresponseStatus, and an optional stringdeliveryType (by
default, the empty string), perform the following steps:
To setup the resource timing entry for
PerformanceResourceTimingentry given DOMString
initiatorType, DOMString requestedURL, fetch timing infotimingInfo, a DOMString cacheMode, a response body infobodyInfo, a statusresponseStatus, and an optional DOMString deliveryType (by
default, the empty string), perform the following steps:
Assert that cacheMode is the empty string,
"local", or "validated".
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 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 timing information.
6.
Privacy Considerations
Statistical fingerprinting is a privacy concern where a malicious web
site might 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
load event on resources can already measure timing to determine cache
hits and misses in a limited fashion, and the cross-origin
restrictions in HTTP Fetch prevent the leakage of any additional
information.
7.
Acknowledgments
Thanks to Anne Van Kesteren, Annie Sullivan, Arvind Jain, Boris
Zbarsky, Darin Fisher, Jason Weber, Jonas Sicking, James Simonsen,
Karen Anderson, Kyle Scholz, Nic Jansma, Philippe Le Hegaret,
Sigbjørn Vik, Steve Souders, Todd Reifsteck, Tony Gentilcore, William
Chan, and Alex Christensen for their contributions to this work.
You are visitor 01402503 — GeezerVison does not store the pages you look up. Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.