Copyright
©
2011
2012
W3C
®
(
MIT
,
ERCIM
,
Keio
),
All
Rights
Reserved.
W3C
liability
,
trademark
and
document
use
rules
apply.
This
specification
defines
an
interface
for
web
applications
to
access
the
complete
timing
information
related
to
HTML
elements.
for
resources
in
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/.
W3C publishes a Candidate Recommendation to indicate that the document is believed to be stable and to encourage implementation by the developer community.
The entrance criteria for this document to enter the Proposed Recommendation stage is to have a minimum of two independent and interoperable user agents that implementation all the features of this specification, which will be determined by passing the user agent tests defined in the test suite developed by the Working Group.
The Working Group does not expect to advance to Proposed Recommendation prior to . A preliminary implementation report is available and will be updated during the Candidate Recommendation period. This is a work in progress and may change without any notices.
This
is
the
Last
Call
The
Working
Draft
of
the
Resource
Timing
specification.
Group
intends
to
gain
implementation
experience
before
recommending
implementations
to
remove
their
vendor
prefixes.
Please
send
comments
to
public-web-perf@w3.org
(
archived
)
with
[ResourceTiming]
at
the
start
of
the
subject
line
by
15
.
A diff document with the previous draft is available.
This document is produced by the Web Performance Working Group. The Web Performance Working Group is part of the Rich Web Clients Activity in the W3C Interaction Domain .
You can find the latest Editor's Draft of this document in the W3C's Mercurial repository , which is updated on a regular basis.
Publication
as
a
Working
Draft
Candidate
Recommendation
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 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
[NavigationTiming]
addresses
part
of
the
problem
by
providing
timing
information
associated
with
a
navigation,
this
document
introduces
the
ResourceTiming
interface
to
allow
Javascript
JavaScript
mechanisms
to
collect
complete
timing
information
related
to
resources
on
a
document.
For
example,
the
following
Javascript
JavaScript
shows
a
simple
attempt
to
measure
the
time
it
takes
to
fetch
a
resource:
<!doctype html> <html> <head> </head> <body onload="loadResources()"> <script> function loadResources() { var start = new Date().getTime(); var image1 = new Image(); image1.src = 'http://w3c-test.org/webperf/image1.png'; image1.onload = resourceTiming; var resourceTiming = function() { var now = new Date().getTime(); var latency = now - start; alert("End to end resource fetch: " + latency); }; } </script> <img src="http://w3c-test.org/webperf/image0.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://w3c-test.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> <body onload="loadResources()"> <script> function loadResources() { var image1 = new Image(); image1.src = 'http://w3c-test.org/webperf/image1.png'; image1.onload = resourceTiming; } function resourceTiming() {var resourceList = window.performance.getEntriesByType(window.performance.PERF_RESOURCE); for (i = 0; i < resourceList.length; i++)var resourceList = window.performance.getEntriesByType("resource"); for (i = 0; i < resourceList.length; i++) {if (resourceList[i].initiatorType == window.performance.INITIATOR_IMAGE)if (resourceList[i].initiatorType == "img") { alert("End to end resource fetch: "+ resourceList[i].responseEnd - resourceList[i].startTime); } } } </script> <img id="image0" src="http://w3c-test.org/webperf/image0.png"> </body> </html>
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 RFC2119. For readability, these words do not appear in all uppercase letters in this specification. [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. [Web IDL]
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.
[DOM3CORE]
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. [ECMA262]
This section is non-normative.
The PerformanceResourceTiming interface facilitates timing measurement of downloadable resources on the root page. It represents the timing information related to resources that initiate network downloads. For example, this interface is available for XMLHttpRequest objects [XMLHttpRequest] , HTML elements [HTML5] such as iframe , img , script , object , audio , video , embed , and link with the link type of stylesheet , and SVG elements [SVG] such as svg .
The term "resource" is also used to refer to these elements in this work.
PerformanceResourceTiming
Interface
The
PerformanceResourceTiming
interface
must
include
all
resources
fetched
from
the
networking
layer
by
the
current
browsing
context.
context
.
Resources
that
are
retrieved
from
the
user
agent's
networking
layer
cache
must
be
included
in
the
PerformanceResourceTiming
interface.
The rest of this section is non-normative.
Examples:
src
attribute
of
two
HTML
IMG
elements,
the
fetch
of
the
resource
initiated
by
the
first
HTML
IMG
element
should
be
included
in
the
PerformanceResourceTiming
interface.
The
user
agent
might
not
re-request
the
URL
from
the
networking
layer
for
the
second
HTML
IMG
element,
instead
using
an
in-memory
browser
cache.
In
this
case,
there
is
only
a
single
request
sent
to
the
networking
layer
for
retrieval,
so
the
fetch
of
the
resource
by
the
first
IMG
element
would
be
the
only
occurrence
in
the
PerformanceResourceTiming
interface.
src
attribute
of
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
in
the
PerformanceResourceTiming
interface.
XMLHttpRequest
is
generated
twice
for
the
same
canonical
URL,
both
fetches
of
the
resource
would
be
included
in
the
PerformanceResourceTiming
interface.
This
is
because
the
user
agent
must
validate
both
requests
from
the
networking
layer,
even
if
the
resource
is
in
a
disk
cache
from
the
first
request.
IFRAME
element
is
included
on
the
page,
then
only
the
resource
requested
by
IFRAME
src
attribute
is
included
in
the
PerformanceResourceTiming
interface.
Sub-resources
requested
by
the
IFRAME
document
will
be
included
in
the
IFRAME
document's
PerformanceResourceTiming
interface
and
not
the
parent
document's
PerformanceResourceTiming
interface.
IMG
element
has
a
data:
URI
as
its
source,
then
this
resource
will
not
be
included
in
the
PerformanceResourceTiming
interface.
By
definition
data:
URI
contains
embedded
data
and
does
not
require
access
to
the
networking
layer.
The
user
agent
may
choose
to
limit
how
many
resources
are
included
in
the
PerformanceResourceTiming
interface.
The
recommended
maximum
minimum
number
of
resources
is
150,
though
this
may
be
changed
by
the
user
agent.
setResourceTimingBufferSize
can
be
called
to
request
a
change
to
this
limit.
PerformanceResourceTiming
Interface
interface PerformanceResourceTiming : PerformanceEntry { readonly attribute DOMString initiatorType; // "css", "embed", "img", "link", "object", "script", "subdocument", "svg", "xmlhttprequest", "other"readonly attribute unsigned long long ; readonly attribute unsigned long long ; readonly attribute unsigned long long ; readonly attribute unsigned long long ; readonly attribute unsigned long long ; readonly attribute unsigned long long ; readonly attribute unsigned long long ; readonly attribute unsigned long long ; readonly attribute unsigned long long ; readonly attribute unsigned long long ; readonly attribute unsigned long long ;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; };
The PerformanceResourceTiming interface participates in the Performance Timeline and extends the following attributes of the PerformanceEntry interface:
The
name
attribute
must
return
the
resolved
URL
of
the
requested
resource.
This
attribute
must
not
change
even
if
the
fetch
redirected
to
a
different
URL.
The
entryType
attribute
must
return
the
DOMString
.
PERF_RESOURCE
resource
The
startTime
attribute
must
return
a
DOMHighResTimeStamp
with
the
time
immediately
before
the
user
agent
starts
to
queue
the
resource
for
fetching.
fetching
.
If
there
are
HTTP
redirects
or
equivalent
when
fetching
the
resource
resource,
and
if
all
the
redirects
or
equivalent
are
from
the
same
origin
as
the
current
document,
document
or
the
Timing-Allow-Origin
HTTP
response
header
rules
are
met,
this
attribute
must
return
the
same
value
as
redirectStart
.
Otherwise,
this
attribute
must
return
the
same
value
as
fetchStart
.
The
duration
attribute
must
return
a
timestamp
DOMHighResTimeStamp
equal
to
the
difference
between
responseEnd
and
startTime
,
respectively.
initiatorType
attribute
This
On
getting,
the
initiatorType
IDL
attribute
must
return
one
of
the
following
DOMStrings
representing
the
type
of
object
that
initiated
the
request
for
the
resource:
<link>
element.
INITIATOR_CSS
:
css
:
The
initiator
is
any
CSS
resource
downloaded
via
the
url()
syntax,
such
as
@import
url()
,
background:
url()
,
etc.
embed
:
The
initiator
is
the
src
attribute
of
the
HTML
<script>
<embed>
element.
img
:
The
initiator
is
the
src
attribute
of
the
HTML
<img>
element.
link
:
The
initiator
is
the
data
href
attribute
of
the
HTML
<object>
<link>
element.
object
:
The
initiator
is
the
src
data
attribute
of
the
HTML
<frame>
or
<iframe>
<object>
script
:
The
initiator
is
the
src
attribute
of
the
HTML
<embed>
<script>
element.
subdocument
:
The
initiator
is
the
src
attribute
of
the
HTML
<audio>
<frame>
<audio>
<iframe>
svg
:
The
initiator
is
the
src
or
poster
attribute
of
the
<video>
<svg>
element
<source>
element
associated
with
a
<video>
<svg>
element.
xmlhttprequest
:
The
initiator
is
<svg>
element
.
other
:
The
initiator
is
not
of
any
type
listed
above.
redirectStart
attribute
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, and the Timing-Allow-Origin HTTP response header rules are met, this attribute must return the starting time of the fetch that initiates the redirect. Otherwise, this attribute must return zero.
redirectEnd
attribute
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, and the Timing-Allow-Origin HTTP response header rules are met, 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.
fetchStart
attribute
This
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.
domainLookupStart
attribute
This attribute must return the time immediately before the user agent starts the domain name lookup for the resource. If a persistent connection [ RFC 2616 ] 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-Origin HTTP response header rules apply.
domainLookupEnd
attribute
This attribute must return the time immediately after the user agent finishes the domain name lookup for the resource. If a persistent connection [ RFC 2616 ] 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-Origin HTTP response header rules apply.
connectStart
attribute
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 [ RFC 2616 ] 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 the Timing-Allow-Origin HTTP response header rules apply.
connectEnd
attribute
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 [ RFC 2616 ] 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. It must not include other time interval 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-Origin HTTP response header rules apply.
secureConnectionStart
attribute
This attribute is optional. User agents that don't have this attribute available must set it as undefined. When this attribute is available, if the scheme of the current page is HTTPS , this attribute must return the time immediately before the user agent starts the handshake process to secure the current connection. If the secureConnectionStart attribute is available but HTTPS is not used, this attribute must return zero.
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-Origin HTTP response header rules apply.
requestStart
attribute
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-Origin HTTP response header rules apply.
responseStart
attribute
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-Origin HTTP response header rules apply.
responseEnd
attribute
This attribute must return the time immediately after the user agent finishes receiving the last byte of the resource from from relevant application caches or from local resources.
partial interface Performance { void clearResourceTimings(); void setResourceTimingBufferSize (in unsigned long maxSize);partial interface Performance { void clearResourceTimings(); void setResourceTimingBufferSize(unsigned long maxSize);attribute Function onresourcetimingbufferfull;attribute Function onresourcetimingbufferfull; };
clearResourceTimings
method
The
method
clearResourceTimings
clears
the
buffer
used
to
store
the
current
list
of
PerformanceResourceTiming
resources.
No parameters
No return value
No additional exceptions
setResourceTimingBufferSize
method
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.
If
this
method
is
not
called,
the
default
maximum
number
of
user
agent
should
store
at
least
150
PerformanceResourceTiming
resources
stored
must
be
150,
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. The maxSize parameter will apply only after the clearResourceTimings method is called.
Parameters
in
maxSize
type
of
unsigned
long
The maxSize parameter sets the maximum number of PerformanceResourceTiming resources that will be stored in the buffer.
No return value
No additional exceptions
onresourcetimingbufferfull
attribute
The callback onresourcetimingbufferfull is triggered when the buffer used to store the list of PerformanceResourceTiming is full. The callback can be used to package existing PerformanceResourceTiming resources and clear the buffered PerformanceResourceTiming list. While executing the onresourcetimingbufferfull callback, PerformanceResourceTiming will continue to be collected beyond the maximum limit of the resources allowed in the PerformanceResourceTiming interface until one of the following occurs:
clearResourceTimings
is
called
-
The
PerformanceEntryList
will
begin
with
the
n+1th
item
if
it
exists
and
the
first
n
elements
are
released,
where
n
is
the
maximum
number
of
resources
allowed
in
the
PerformanceResourceTiming
interface.
If
the
n+1th
item
does
not
exist,
the
buffer
is
cleared.
The
max
length
of
the
PerformanceEntryList
does
not
change
unless
otherwise
specified
by
setResourceTimingBufferSize
.
setResourceTimingBufferSize
is
called
-
The
PerformanceEntryList
will
extend
and
/
or
truncate
to
the
buffer
size
specified.
clearResourceTimings
or
setResourceTimingBufferSize
is
called
during
the
execution
of
the
onresourcetimingbufferfull
callback
-
no
updates
are
made
to
the
PerformanceEntryList
.
Information
from
cross-origin
resources
must
be
included
in
the
PerformanceResourceTiming
interface.
In
the
absence
of
the
Timing-Allow-Origin
HTTP
response
header,
these
attributes
must
be
set
to
zero:
redirectStart
,
redirectEnd
,
domainLookupStart
,
domainLookupEnd
,
connectStart
,
connectEnd
,
requestStart
,
responseStart
,
and
responseEnd
.
secureConnectionStart
,
if
supported
by
the
user
agent.
The
terms
origin
and
same
origin
are
defined
by
The
HTTP
Origin
Header.
[ORIGIN]
[IETF
RFC
6454]
The term cross-origin is used to mean non same origin .
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
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 | "*"
origin-list-or-null
is
defined
by
The
HTTP
Origin
Header.
[ORIGIN]
[IETF
RFC
6454]
Vendor-specific
proprietary
user
agent
extensions
to
this
specification
are
strongly
discouraged.
If
such
extensions
are
needed,
e.g.
e.g.,
for
experimental
purposes,
vendors
must
use
the
following
extension
mechanisms:
If
the
an
extension
to
be
added
is
an
INITIATOR
the
initiatorType
,
IDL
attribute
return
value
is
needed
for
an
experimental
initiator
type,
on
getting
the
INITIATOR
initiatorType
must:
IDL
attribute,
vendors
MUST
return
a
DOMString
that
uses
the
following
convention:
[vendorprefix]-[name]
Where,
[vendorprefix]
is
a
non-capitalized
name
that
identifies
the
[name]
is
a
If the extension is a new timing attribute, it must:
Illustration
This section is non-normative.
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.
setResourceTimingBufferSize
method.
PERF_RESOURCE
.
resource
.
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.
When persistent connection [ RFC 2616 ] 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.
onresourcetimingbufferfull
must
be
triggered.
onresourcetimingbufferfull
callback,
add
them
to
the
temporary
buffer
.
clearResourceTimings
method
is
called
in
the
onresourcetimingbufferfull
callback,
clear
all
PerformanceResourceTiming
objects
in
the
primary
buffer
.
Copy
all
PerformanceResourceTiming
objects
in
the
temporary
buffer
to
the
primary
buffer
.
setResourceTimingBufferSize
method
is
called
in
the
onresourcetimingbufferfull
callback,
set
the
maximum
size
of
the
primary
buffer
to
the
maxSize
parameter.
If
the
maxSize
parameter
is
larger
than
the
previous
size
of
the
primary
buffer
,
append
PerformanceResourceTiming
objects
in
the
temporary
buffer
to
the
primary
buffer
up
to
the
maxSize
parameter.
The
value
of
the
timing
attributes
must
monotonically
increase
to
ensure
timing
attributes
are
not
skewed
by
adjustments
to
the
system
clock
during
while
fetching
the
navigation.
resource.
The
difference
between
any
two
chronologically
recorded
timing
attributes
must
never
be
negative.
The
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.
This section is non-normative.
When
giving
various
timing
information
of
how
a
resource
is
requested
and
process,
the
ResourceTiming
The
PerformanceResourceTiming
interface
potentially
exposes
such
timing
information
for
a
resource
to
any
web
page
that
has
this
resource
included.
included
that
resource.
To
limit
the
access
to
the
ResourceTiming
PerformanceResourceTiming
interface,
the
same
origin
policy
is
enforced
by
default.
Additionally,
resource
default
and
certain
attributes
are
set
to
zero,
as
described
in
Section
4.5
Cross-origin
Resources
.
Resource
providers
can
explicitely
explicitly
allow
all
timing
information
to
be
collected
over
for
a
resource
by
adding
the
Timing-Allow-Origin
HTTP
response
header,
which
specifies
the
domains
that
are
allowed
to
access
the
timing
information.
This
section
Statistical
fingerprinting
is
non-normative.
Similar
to
a
privacy
concern
where
a
malicious
web
site
may
determine
whether
a
user
has
visited
a
third-party
web
site
by
measuring
the
discussion
timing
of
cache
hits
and
misses
of
resources
in
the
Privacy
section.
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.
We would like to sincerely thank Karen Anderson, Darin Fisher, Tony Gentilcore, Nic Jansma, Arvind Jain, Kyle Scholz, Jonas Sicking, James Simonsen, Steve Souders, Annie Sullivan, Sigbjørn Vik, Jason Weber to acknowledge their contributions to this work.