RE: [ResourceTiming] Resource timing details

Hi Tony,

Regarding:

> type attribute

Apologies if this has been covered, but what is the rationale for basing the type attribute on the initiator element rather than content-type of the resource?

Here are some of the reasons why we are thinking the download initiator type is more appropriate to expose than the Content Type of the resource:

*         The authoring of a page defines the resources being downloaded, directly caused by page components (HTML elements and JavaScript objects, aka "initiators").  Knowing just the Content Type of the resource makes it hard to track the download back to the specific cause in the HTML.

o   For example, a XHR can download text, HTML, XML, JSON, etc -- any Content-Type.  If the XHR downloaded "application/javascript", it might not be obvious that the download was caused by the XHR vs. a SCRIPT element on the page.


*         It's easier to organize resources by initiator type (IMG vs. SCRIPT) than the multiple Content Types that work for each element (image/png or image/jpeg for IMG, text/javascript or application/javascript for SCRIPT).


*         The Content Type might not match the element/initiator type in cases of errors

o   An IMG could fetch a 404'd resource, whose Content Type is text/html, and it would not be obvious this was an IMG download


*         Initiator type is known immediately - Content Type isn't available until the HTTP headers are returned (and would be missing if there was an error with the download)


*         Content-type is not available to script today so we would have to determine if there was a security concern with exposing it

- Nic

From: public-web-perf-request@w3.org [mailto:public-web-perf-request@w3.org] On Behalf Of Tony Gentilcore
Sent: Tuesday, May 17, 2011 1:31 PM
To: public-web-perf@w3.org
Subject: [ResourceTiming] Resource timing details

Now that some of the higher level issues are resolved, I took a more detailed pass through the spec. This is kind of a mix of questions and comments.

Section 4.2

> "A downloadable resource is any resource that the user agent asks the networking layer to retrieve."

I believe this means we won't have entries for data: URLs. It might be nice to explicitly mention that in an example.

In general, this relies too heavy on examples. The examples should be marked non-normative and we should have an appropriate normative description.

Section 4.3

> type attribute

Apologies if this has been covered, but what is the rationale for basing the type attribute on the initiator element rather than content-type of the resource?

> url attribute

I think we all understand this, but the spec should probably explicitly state that this is the resolved URL (as opposed to the string found in the attribute). http://dev.w3.org/html5/spec/Overview.html#resolve-a-url

> fetchStart attribute: "This attribute must return the time immediately before the user agent starts to fetch the resource."

This doesn't seem to adequately distinguish it from resourceFetchStart (which I believe we discussed should be renamed resourceStart).

> fetchStart attribute: "This time should not be overwritten if the user agent retries fetching the same resource due to failures."

This sounds like a must-level requirement rather than a should-level. Also, wouldn't this be true of some other attributes as well?

Section 4.4

> clearResourceTimings method: Only the first 150 PerformanceResourceTiming resources will be stored, unless otherwise specified by the user agent or setResourceTimingBufferSize.

This sentence doesn't relate to the functioning of this method. The buffer limit behavior needs to be specified in the processing model.

> getResourceTimings method

I thought we talked about dropping the get-by-type functionality. Shouldn't this instead take an optional location and then we can drop the getResourceTimingsByLocation() method?

> setResourceTimingBufferSize method: If this method is not called, the default maximum number of PerformanceResourceTiming resources stored is 150, unless otherwise specified by the user agent.

This needs to use more precise verbs defined in section 2 (MUST, RECOMMENDED, etc). I think the buffer size should be a variable defined and used during the processing model. The normative requirement for this method should really just be something along the lines of "The setResourceTimingBufferSize(size) method, when invoked, must set the value of |resource-timing-buffer-size| to |size|"

> onbufferfull attribute

Do we still need this handler? Isn't it enough to be able to control the max size?

Section 5.1
These requirements only describe the behavior for each resource, but they should also include the behavior during the overall lifecycle of the page (for instance when is the resource timing list created/destroyed, when does resource collection begin/end?)

These requirements need to explain when a resource is actually added to the resource timing list. Is it added at resourceStart or at responseEnd. If resourceStart, then we also need to define how the rest of the attributes behave while the fetch is pending.

This also needs to explain what happens when the buffer limit is reached. For instance, do additional resources get dropped on the floor or does everything get shifted? At what point in the steps is the buffer limit checked?

When and exactly how the url and type attributes are populated is also missing.

> For each resource initiated on the page:
This isn't specific enough to be implemented. It should be tied to something in the HTML5 spec.

> If the fetched resource results in an HTTP redirect or equivalent, then...
Since this happens after all the other attributes are already set, it would be possible to observe a redirect resource with all the network values in place for the redirect itself, before they have flipped over to the resource being redirected to. I don't think this is what we want.

-Tony