Resource Timing
Home Page: https://w3c.github.io/resource-timing/
License: Other
Resource Timing defines an interface for web applications to access the complete timing information for resources in a document.
See also Web performance README
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "github-actions[bot]")
Since we also return resource timing entries for cached resources, it should be specified if transferSize should return the same value it had during the first load, or just an estimation (body+headers).
Secondly, since we sometimes get 4XX/5XX responses with content, it needs to be clarified how we handle this case. I assume it would still return non-zero values, even if this is not the body of the resource we requested?
Also, while usually encodedBodySize is the same as the Content-Length response header, in some cases it could differ. I assume we want the actual number of bytes on the wire.
domainLookupStart of type DOMHighResTimeStamp, readonly
current definition says:
[[
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.
]]
but what do we return if the resource is of the same-origin but not in the cache? Seems like it should the same value as fetchStart.
History records the redirected-to URL and triggering history.back() on an iframe creates a ResourceTiming object with name attribute set to said URL.
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 -- current definition.
Similarly, our processing section records the resolved URL of the requested resource. As such, I don't believe this is a RT spec bug, but the fact that all implementations are subject to this does indicate that we may want to add some language to make this explicit.
https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/Hs5-wPpCPZc/7BVwLbfMAAAJ
One thing that's a bit unclear about this spec is how it would handle cached loads. Would it return the nextHop for the original fetch or would it return a value like "cache". FWIW at FB we're already differentiating cache via transfer_size = 0. -- @bmaurer
Inspecting FF's (shipped in M45) implementation: they return the value of the original fetch, which is a sensible implementation given that current definition constrains the returned value to ALPN id's.
That said, from a developer perspective, returning a value like "cache" or "local" seems (more, I think) sensible. Doing so would remove the need for attribute gymnastics around transferSize (see #42 (comment)) to figure out if a resource is cached.. Alternatively, we can return an empty string to indicate that there is no "next hop".
@valenting @toddreifsteck any thoughts or opinions on this one?
I couldn't find when the "add a PerformanceResourceTiming entry" algorithm is defined to run, and I have ran into trouble in WebKit with an example similar to the one in Example 2 (only with XHR), where at the onload event, there is expectation that the entry should already be there.
Is the algorithm's running point well defined? Do we have tests for that?
From https://lists.w3.org/Archives/Public/public-web-perf/2015Jan/0069.html
[[
For a quick example go to https://httpbin.org/ and try this out in the
console:
var xhr = new XMLHttpRequest();
xhr.open('GET', 'https://foo:[email protected]/basic-auth/foo/bar');
xhr.send();
setTimeout(function () { alert('Your password is: ' +
performance.getEntriesByType('resource').pop().name.split('@')[0].split(':').pop()
)}, 500);
Using basic auth may not be a great idea, but people still do,
inadvertently exposing passwords to other javascript on their pages.
]]
The timing-allow-check is not well defined for same-origin resources, and the way it is used in the definition of transferSize, encodedBodySize and decodedBodySize does not limit it to third-party resources.
We should either improve the definition or limit the check's use. (I believe the former would be better)
Hi All,
I am using the R-T to get the xhr timing info. But sometimes I could not get the info and it is reproduced. I COULD get the xhr timing info with the svg img, but resource array returns 0 length without this img. Could someone there help me with this strange issue? I am new to this. :-)
Codes are here and Chrome v43 is used.
<html>
<head>
<title>index page</title>
<script type="text/javascript">
function showCustomer(str) {
var xmlhttp;
if (str == "") {
document.getElementById("txtHint").innerHTML = "";
return;
}
if (window.XMLHttpRequest) { // code for IE7+, Firefox, Chrome, Opera, Safari
xmlhttp = new XMLHttpRequest();
} else { // code for IE6, IE5
xmlhttp = new ActiveXObject("Microsoft.XMLHTTP");
}
xmlhttp.onreadystatechange = function() {
if (xmlhttp.readyState == 4 && xmlhttp.status == 200) {
document.getElementById("txtHint").innerHTML = xmlhttp.responseText;
}
}
xmlhttp.open("GET", "//ajax.googleapis.com/ajax/libs/jquery/1.11.1/jquery.js", true);
xmlhttp.send();
}
</script>
</head>
<body>
<script type="text/javascript">showCustomer('baidu');</script>
<span id="rt-unsupported" class="hidden">API not supported</span>
<!-- IF I REMOVE THE SVG IMG, I COULD NOT GET THE XHR TIMING INFO -->
<div>
<h2>Test 2 - Image</h2>
<img src="http://www.sitepoint.com/wp-content/themes/sitepoint/assets/svg/sitepoint.svg" />
<ul id="img-list">
</ul>
</div>
<h1>It works!</h1>
<p>This is the default web page for this server.</p>
<p>The web server software is running but no content has been added, yet.</p>
<script type="text/javascript">
(function() {
if (!('performance' in window) ||
!('getEntriesByType' in window.performance) ||
!(window.performance.getEntriesByType('resource') instanceof Array)
) {
document.getElementById('rt-unsupported').classList.remove('hidden');
} else {
window.addEventListener('load', function() {
var resources = window.performance.getEntriesByType('resource');
console.log(resources);
});
}
})();
</script>
</body>
</html>
Hi,
I'm currently loading audio files on a website, and I suspect that they're taking a long time. getEntriesByType does not return any entries for the audio. How can I measure the loading time for these resources?
Here it points me towards resource timing level 2, but I can't find audio resource timing anywhere. Any pointers?
Expressing RT in terms of Fetch will force us to clarify a lot of the current edge cases:
Some ideas on mechanics of how to accomplish this in #36 (comment). This will be a substantial effort with required changes both in RT and Fetch specs.
HTTP/2 allows the server to "push" resources to the client. We should figure out if and how these should be exposed via ResourceTiming.
The introduction of integer values (transferSize, encodedBodySize and decodedBodySize) means that we can no longer use 0 as a value indicating that a 3rd-party origin did not pass the timing-allow check.
We need to define a way in which a developer can know if a certain 3rd party resource didn't include the appropriate headers, or was genuinely zero sized.
Probably the same language as connectionStart.
See #27
Timing-Allow-Origin = "Timing-Allow-Origin" ":" origin-list-or-null | "*"
Definition of origin-list-or-null: https://tools.ietf.org/html/rfc6454#section-7.1
7.1. Syntax
The Origin header field has the following syntax:
origin = "Origin:" OWS origin-list-or-null OWS
origin-list-or-null = %x6E %x75 %x6C %x6C / origin-list
origin-list = serialized-origin *( SP serialized-origin )
serialized-origin = scheme "://" host [ ":" port ]
; <scheme>, <host>, <port> from RFC 3986
My read of the above ABNF is that TAO should allow a space separated list of origins. However, ACAO header also has origin-list-or-null but has a comment indicating that it's a single origin only -- is this a special ACAO restriction?
Today, Chrome allows a space separated list of origins. FF does not. Edge.. not sure.
@toddreifsteck how does Edge handle this?
@mnot @reschke can you sanity check this as well? Am I reading this correctly?
While digging around WebKit's resource timing code, I realized that initiatorType is not well defined in scenarios where the same resource is requested by multiple initiators.
e.g. If an image is requested first by <img> and later on by a CSS url(), which initiator type should it have? To me it makes sense that it would be defined to be based on the first element that initiated that fetch, so in the above scenario it would be "img" rather than "css".
If the app is ServiceWorker-enabled then all fetches are routed to the SW, where they may be fulfilled from local cache, rewritten, forwarded to remote server, etc. However, the SW script may be terminated at any point and may need to be (re)started prior to servicing the request - e.g. navigation request spools up a worker, which is then killed, and a new worker is started up to service a subresource fetch.
The application needs to be able to distinguish and measure the worker startup time.
Attribute definition:
workerStart: The workerStart attribute must return a DOMHighResTimeStamp [HR-TIME] with the time immediately before the user agent starts the Worker required to service the request. If the worker process is already available, then this attribute must return the same value as fetchStart.
For processing section update (add new step before 3.5):
If the current browsing context has a registered Service Worker, immediately before a user agent starts the worker process or forwards the request to an existing worker process, record the current time as workerStart.
Does that look reasonable? Anything I'm forgetting? </handwaving>
P.S. Once we iron out the language here, we'll need to make a similar update to Navigation Timing..
I can't remember if this has been discussed already.
I know that PerformanceTimeline2 and PerformanceObserver are still being spec'd out (http://www.w3.org/TR/2015/WD-performance-timeline-2-20150716/), but I would like to ensure that once ResourceTiming events get wired into PerformanceObserver, RT still fires PO events even if the "legacy" ResourceTiming buffer is full.
The legacy buffer was capped (e.g. at 150 entries) to ensure an app would not have an growing buffer of RT data even if no one was listening.
But when someone is listening via a PerformanceObserver, we know that someone cares for the data, and should be able to safely deliver those RT entries to the listener even if the regular RT array is full.
An attacker attacker.example can figure out what resources a stylesheet target.example loads by including it on attacker.example and using either the resource timing (shipped) or service worker (about to ship) API. This violates SOP. (@annevk)
https://lists.w3.org/Archives/Public/public-web-perf/2015Feb/0065.html
There's some differences in the way browsers treat requests that don't
return a response. FF Nightly and IE 11 both create PerformanceResourceTiming entries for
these requests, whereas Chrome & Canary don't. The RT spec isn't explicit as to whether requests that miss a response should be included. -- @andydavies
In navtimg, we have:
[[
responseEnd of type DOMHighResTimeStamp, readonly
This attribute MUST return a DOMHighResTimeStamp with a time value equal to the time immediately after the user agent receives the last byte of the current document or immediately before the transport connection is closed, whichever comes first. The document here can be received either from the server, relevant application caches or from local resources.
]]
In RT, we have:
[[
responseEnd of type DOMHighResTimeStamp, readonly
This attribute MUST return the time immediately after the user agent finishes receiving the last byte of the resource from relevant application caches or from local resources.
]]
I presume the navtiming is more accurate (it also matches the responseStart definition).
Why is onresourcetimingbufferfull an EventHandler on the Performance object rather than a GlobalEventHandler?
Is there a reason why failed requests are not being listed in the entries?
ForEach resource, it could iterate as:
readonly attribute unsigned long long transferSize;
readonly attribute unsigned long long encodedBodySize;
readonly attribute unsigned long long decodedBodySize;
Maybe I missed where the spec says it, but I don't think these should be exposed for resources you wouldn't normally have access to. You could use the byte lengths to do all kinds of information leakage across origins.
It's unclear to me what the expected behaviour is from user agents with regards to cached resources.
Current behaviour as observed in Chrome and Firefox:
Natural first view (cold cache):
performance.getEntries() includes these (no size fields yet per chromium #467945).performance.getEntries() includes these.Natural second view (cache primed, navigating to the same page again):
performance.getEntries() includes these.performance.getEntries() does not include these.Manual reload:
performance.getEntries() includes these.performance.getEntries() includes these (as expected with a small transferSize but with full *BodySize).The spec has wording about "relevant application caches", and it seems both browsers implement this for the reload/304 scenario. But the behaviour for natural cache hits is inconsistent (e.g. where the resource is within the local max-age and therefor no request goes to the network).
I'm also not sure what the expected behaviour should be. On the one hand it seems useful to be able to instrument actual network activity (as observed in the timeline). On the other hand it also seems useful to be able to calculate all resources used by the user agent (regardless of where they come from).
Also with Web Manifesto in mind, it seems best to include them all - which will allow authors to satisfy both uses cases (by calculating the field of interest, either transferSize or *BodySize)
Exposing information about the nature of a TLS connection used to fetch a resource could enable a number of useful types of debugging:
This type of information can already be collected by using Flash to open a direct socket to port 443 if the domain exposes a socket policy (https://www.linshunghuang.com/papers/mitm.pdf). This suggests that exposing the same information for resources with Access-Control-Allow-Origin would be a reasonable measure.
I don't see a way for an app to determine/get the current buffer size. An app might want to the current size if, for example, the app gets a resourcetimingbufferfull event.
If there is way for an app to get this data, please let me know.
Hi,
I wasn't sure about the whether these are 2 different specs, and what is the state of their drafting.
It's said in the spec of resource timing that:
"The audio and video elements are specifically covered in the Resource Timing Level 2 specification and not in this version of the specification." (http://www.w3.org/TR/resource-timing/#introduction-1).
Resource-timing 2 looks like copy&paste of an old version of resource-timing. (http://w3c.github.io/resource-timing/).
Thanks in advance
See http://www.stevesouders.com/blog/2014/11/25/serious-confusion-with-resource-timing/ from Steve Souders
We at Vimeo are working on uploading straight to Google Cloud Storage. Occasionally I notice OPTIONS requests taking a long time to respond (10-30 sec).
Here is one example: https://gist.github.com/vayam/d752cf31eeedc4849766#file-gistfile1-txt-L2164
I would like to log OPTIONS request timings so I can report to Google Cloud support. Unfortunately, the HTTP method is not recorded in the resource timing spec. Right now I can't distinguish b/w PUT vs OPTIONS.
From the spec The name attribute must return the resolved URL of the requested resource.
I propose adding method attribute to it.
I would like to hear your feedback on this.
/cc @toddreifsteck
I've been looking at specific ways to add more detailed initiator info that would enable getting the dependency tree info from resource-timing (as briefly discussed during TPAC).
When digging deeper into the spec and the current definitions, I found some unfortunate surprises:
initiatorType sometime points at the type of the resource itself, and sometimes points at the type of the initiator (specifically, with the "css" initiator type)Furthermore, for the purposes of a dependency tree, initiator definition needs to vary from the one practiced with initiatorType (and match more closely what happens in the various browser dev tools):
I think that for the purposes of initiatorType, we'd better define the behavior as it is currently shipped.
For the purposes of the "dependency initiator", we probably need to define something slightly different. As initiatorType is already shipped and the term "initiator" seems to be overloaded, we probably also want to find a new name.
Add those fields to PerformanceResourceTiming.
Protocol - SSL 1.0, SSL 2,0, SSL 3.0, TLS 1.1, TLS 1.2, TLS 1.3...
Cipher - AES_128_GCM...
Key exchange - ECDHE_RSA...
Signature algorithm - SHA256RSA...
Signature hash - SHA256...
Thumbprint algorithm - SHA1...
Public key - RSA...
Public key bits - 2048...
Will it be possible to add a new filed in the RT API to check if the resource is downloaded Sync/Asynchronously. This will help in identifying whether a resource is blocking or not.
Please let me know if its possible by other means.
On Fri, May 22, 2015 at 10:24 PM, Boris Zbarsky [email protected] wrote:
https://w3c.github.io/resource-timing/#terminology clearly says:Throughout this work, all time values are measured in milliseconds
since the start of navigation of the document. For example, the
start of navigation of the document occurs at time 0. The term
current time refers to the number of milliseconds since the start
of navigation of the document until the current moment in time.What exactly does "the start of navigation of the document" mean in workers? That's the only thing here that actually needs serious standardization work, by the way: exposing interfaces is easy; it's making them behave the same way in different UAs that's the interesting part that requires a standard.
HEIST paper, ArsTechnica coverage, Twitter discussion
Reading through the paper, the core observation is: TCP congestion control can be (ab)used to infer size of a (cross-origin) resource. Roughly:
Given both of the above, you can compute the time delta between when the headers were received and response end:
If TCP connection is brand new, the above can effectively tell you if response is <14KB. An extended version of this for beyond IW10 is:
Aside, but related, it’s possible to estimate RTT via javascript: if you know the RTT and have a model for what you expect the congestion window to be, you can use that observe if response took >1 RTT and arrive at same results with similar padding technique (knowledge of when response headers are received improves accuracy, but not necessary).
Armed with above, you can apply a compression oracle attack against the origin, ala Breach. That said, I’m dubious of the claims in the paper about how practical this actually is: tripping over a congestion window boundary doubles said congestion window and that ramps quickly and hence the query rate should be low... Am I missing something here?
Mitigations: all existing BREACH recommendations apply.
In terms of practical implications... /cc @annevk @slightlyoff @domenic
Last but not least, scrubbing through RT spec it looks like we introduced a bug in 88bb585?diff=split#diff-eacf331f0ffc35d4b482f1d15a887d3bL543 ~implying that responseEnd is subject to TAO. It's not.. Unless @plehegar had something else in mind here?
From https://bugs.chromium.org/p/chromium/issues/detail?id=568024:
http://w3c.github.io/resource-timing/#dom-performanceresourcetiming-responsestart
Is the first byte the first byte of the first challenge, or the first byte of the actual headers? What about 100 continue responses? Do those really count, or do we care about the actual headers for the response?
I'm inclined to say that the challenge bytes / 100 Continue are valid "responseStart" bytes - i.e. responseStart should capture the time of receipt of 100 Continue / challenge.
@toddreifsteck @annevk how do you guys handle this in your implementations?
if H2 reads only a partial frame..
Is that a valid responseStart marker, or should it reflect receipt of a full frame? Personally I'm leaning towards the latter.
There are cases when a resource fetched over the network has completed downloading, and is available to the browser, but the browser is too busy to read it and parse it. In these cases, the responseStart timestamp is set after the browser becomes free to read the file off its buffer. This incorrectly points to a network problem.
As an example, using WebPageTest, we measured the loading of a particular website, and also captured the network PCAP file of the data transfer. The PCAP file showed that the file had been fetched (all packets arrived at destination) in under 200ms, however the browser reported responseStart at the 1.2second mark. WPT showed that the browser was at 100% CPU utilization and 0% bandwidth utilization during these 1.2 seconds. This indicated that while the file was available locally in some buffer, the browser was too busy to read it, and incorrectly put the blame on the network.
responseStart should stamp when bytes of the response were available, not when the browser was ready to parse themresponseEnd should stamp when the response was completely available, not when the browser finished parsingloadComplete or resourceLoaded or equivalent, indicating when the browser actually finished handling the resource in a way appropriate for that resource (which might include inserting into the DOM, parsing, executing, etc.)I believe 1 & 2 are mostly in line with the spec, we should make it explicit that the browser being unable to load, parse and execute an available resource should not delay the responseStart and responseEnd timestamps, and browsers need to follow this.
This came up as part of the W3C discussion at the Velocity Conference in Santa Clara, CA on 2016-06-22T19:00PDT.
Members in attendance during discussion: (please update list in case I've missed/misspelt anyone)
While working on an issue regarding exposing preconnects in ResourceTiming, it came up that exposing such values that precede startTime would result in negative values for various delta calculations.
Looking at the spec, it doesn't seem like preconnecting is considered beyond treating such connections as "persistent connections". Should it be considered? Should it be exposed? If so, are the negative deltas of that value from startTime a problem?
A couple of weird things spotted while reviewing Blink's implementation docs:
the size, in octets received from a HTTP-network fetch, consumed by the response header fields and the response payload body [RFC7230] if the last non-redirected fetch of the resource passes the timing allow check algorithm.
"last" here seems spurious and confusing. If we have a redirection chain, we can expose the size if the final resource fetch passes TAO checks. Unless I'm missing some weird scenario, that would be the first, last and only non-redirected fetch in that chain.
If there are HTTP redirects or equivalent when navigating and if all the redirects or equivalent are from the same origin [RFC6454], this attribute should include the HTTP overhead of incurred redirects
Is there a particular reason we don't expose the redirection overhead of TAO-enabled redirects? I think we should, unless some security considerations dictate otherwise.
Given the push towards securing the web and growing adoption of HTTP/2 (which requires HTTPS in many UAs), I'd like to propose that we make this a mandatory attribute both in resource and navigation timing.
Quoted from the discussion in [email protected] [1].
It appears that IE has a toJSON method on these that affects what JSON.stringify returns. I see nothing like that in the spec; is it supposed to be there?
So should I add the toJSON() method to PerformanceResourceTiming object and define is as:
toJSON() method:
Returns a json object representing the PerformanceResourceTiming object.In fact should I define it on PerformanceEntry itself (as well as on window.performance.timing) to cover all Performance objects?
What you should do is define a serializer. See http://heycam.github.io/webidl/#idl-serializers and I suspect what you want here is:
serializer = { attribute };
for interfaces that don't inherit from something that needs serialization but want to serialize all their own attributes or
serializer = { inherit, attribute };for ones that want to serialize their own attributes plus whatever their parent interface serializes. This will automatically create a toJSON method that does the right things for you.
I suggest you test what UAs do and whether the spec you write is compatible with that.
Gecko does have a serializer on PerformanceEntry and on PerformanceTiming, for what that's worth.
[1] http://lists.w3.org/Archives/Public/public-web-perf/2014Aug/thread.html#msg0
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.