W3C home > Mailing lists > Public > public-web-perf@w3.org > March 2011

RE: [Resource Timing] Spec updated per Action 3 and Action 4

From: Jatinder Mann <jmann@microsoft.com>
Date: Wed, 30 Mar 2011 21:30:44 +0000
To: public-web-perf <public-web-perf@w3.org>
Message-ID: <EE4C13A1D11CFA49A58343DE361B0B04067E5255@TK5EX14MBXC254.redmond.corp.microsoft.com>
Thanks for all of your very valuable input. We discussed many of these in today's conference call. 

We also discussed in today's call about renaming the type attributes from RESOURCE_* to INITIATOR_* to make it clear that the type attribute is defined as an object that is initiating the resource download. 

Comments inline below.

> Should we include a RESOURCE_FAVICON?

If the favicon is initiated by a LINK, then it should have INITIATOR_LINK. If it's not specified in the page, and the browser downloads it on its own, we will not include it.

> What about OCSP, CRL, intermediate certificates, reputation checking, etc?

Since no objects are initiating the requests for these resources, they should not be included. We should instead capture the timing information with a secureConnectionStart timing data, like we do in the Navigation Timing spec.

> What about page loads initiated by third party apps, e.g. extensions? If the
> resource isn't included in the page, then it should of course not be in the
> resource timings, but what if the extension dynamically adds a section to the
> page itself?

Agree that if the resource isn't included in the page, it shouldn't be included in the resources timing. An example could be a third party plug in downloading resources for its own use. If the third party plugin modifies the page itself, it should follow the existing initiator rules.

> What type do @import stylesheets get, they aren't RESOURCE_LINK_CSS?
> What about WebFonts, and other CSS resources? I think they all use the CSS
> 'url' construct, but will future specs also use that?

We're discussing renaming INITIATOR_LINK_CSS to INITIATOR_LINK to capture all resources that were initiated by a link (e.g., CSS, prefetch and favicon).
We're also discussing renaming INITIATOR_CSSIMAGE to INITIATOR_CSS to capture all resources that were initiated by a CSS (both fonts, images and @import).

> What about the param tag, and longdesc, usemap, classid, codebase, data
> and other attributes which use URLs?

One of the goals of having the initiator attribute is to help web developers group their resources by common initiator type. For less commonly used initiator types, we should rely on INITIATOR_OTHER. The data is not lost, as the web developer can always look at the URL and ID attributes.

> How do we treat resources requested through the browser from a plugin,
> are they included?

As mentioned above, if the third party plugin modifies the page itself, it should follow the existing initiator rules.

> What about other resources fetched by subresources, e.g. a an SVG
> RESOURCE_IMAGE fetching parts of the image? (Can WebFonts include
> subresources?) 

We should consider adding a new initiator type called INITIATOR_SVG that includes all SVG elements and sub-resources that it fetches, just like what we are saying for CSS.

> For (i)frames I guess there will be another
> PeformanceResourceTiming interface in the new document, does a script
> need to recurse through those itself?.

The iframe will have its own Window and thus, it will have its own interface. The root Window will not automatically recurse child windows. The user could iterate through all the frames that are same-origin to gather all their resources.

> I see two categories of downloads, tags (those which can have an id
> attribute), and other (e.g. XHR, WebFonts, plugin resources, @import, etc).
> Would it be worthwhile to distinguish between these? If not here, then at
> least a discussion when defining the id attribute would be in place. Possibly
> also a mention in getResourceTimingsByID, as it can only get some of the
> resources. Given that so many of the resources don't have a DOMID, do we
> need to add an explicit id to them, so they can be referred to more easily?
> Maybe their location in the buffer?

The spec currently defines the id attribute as so:
"This attribute must return the ID attribute of the element that initiated the download request for the resource, if applicable and specified. Otherwise, the attribute must be an empty string."

We discussed on today's call whether or not getResourceTimingsByID is confusing. We're currently thinking about keeping it in.  We can be clear here that with text like so: "the id recorded from the element at the moment the resource was requested."

> What happens when a resource is changed? Either an image being preloaded
> (e.g. through XHR), and then dynamically set later. Do we have two resource
> timings for it, one for the XHR and one for the RESOURCE_IMAGE, and are
> they identical, is the first the network fetch while the second is the cache
> fetch, or don't we keep data for the second at all? 

We tried to explain this in Section 4.2 Resources Included in the PerformanceResourceTiming Interface. This depends on whether the second fetch goes to the networking layer or not. The spec states  "A downloadable resource is any resource that the browser initiates a request for retrieval from the networking layer." If the second fetch goes to the networking layer, it will be a new resource in the PerformanceResourceTiming interface.

> Or when the .src of an
> image is dynamically changed, do we keep the timing data for the old image
> (it might have been an important part of the load process), or do we discard
> the old data and overwrite with the new (even if the new data is no data)?

If the second fetch goes to the networking layer, it will be treated as a new resource in the PerformanceResourceTiming interface. There is never a scenario where we will be overwriting existing data. We can add specific examples for these in Section 4.2 to make it clear.

> Regarding the url, which url is it? The linked in (before redirects), or the final
> one (after redirects, or does this depend on the cross domain setup? Is there
> a need for both, or to flag when they are different?

The URL will be the requested URL and will not be updated for any reason. We should make this clear in the spec.

> redirectEnd and redirectStart should have the same cross domain rules as
> other attributes. Only fetchStart and fetchEnd are not subject to this, so
> maybe use a general note instead of repeating the same text all over.

Agreed. The spec should be updated to reflect this.

> Regarding cross domain regulation, let us not invent the wheel again with yet
> another HTTP header. Webmasters are drowning in headers already, and
> setting up a server requires understanding and keeping track of all of them.
> Let us piggyback on some existing system instead, it will be easier for
> webmasters, and we get additional benefits such as support for a policy file.
> E.g. CSP on https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-
> specification.dev.html
> which is being heavily discussed on public-web-security@w3.org these days.

We looked at other CORS spec and the other HTTP response headers, but did not wish to overload existing headers as they may enable additional behavior that was not intended by someone just trying to gather Resource Timing information.

What state is the CSP spec in? It wasn't very clear? We are worried about taking a dependency on another spec that is not stable. We would rather define the behavior in our own spec and not take a dependency.

> Is there any way we could link definitions of the various attributes to those
> used in the navigationTiming spec? Duplicating code (or spec
> wording) is bad practice ;)

We discussed this in today's call. Many of the phases are similar but the specifics applicable to resources may be different than those that apply to Navigation timing. One is not a subset of the other, you do not necessarily have to follow one spec to implement the other.

> secureConnectionStart doesn't seem to be added yet.

Agreed, this needs to be added. The spec should be updated with this.

> Whenever the spec says "A list of PerformanceResourceTiming resources."
> does it mean an array, or perhaps a nodeList?

This is a Javascript array. We can make this clear in the spec.

> getResourceTimingsByLocation takes a DOMLocator in
> (http://www.w3.org/TR/DOM-Level-3-Core/core.html#Interfaces-
> DOMLocator).
> So we should get all resource timings that happened in column x, or offset
> y?!? Would it not make more sense if the input was 'uri type of DOMString'?
> There is no explanation if the location/uri parameter accepts wildcards, or is
> uniquely matched (and if matched, how, e.g. casing, normalization, etc).

Agreed the input type should be changed to URI string. This is not a wildcard, the user could apply their own filtering via script.

> getResourceTimingsById should presumably return a single item, not a list?
> Possibly the same for getResourceTimingsByLocation.

An element with an id could change its source and get a second resource, both of these would be included with the same id in the PerformanceResourceTiming interface.

> "is called during the execution of the onbufferfull callback" - is this
> sufficiently clear, included in a multithreaded environment? SetTimouts
> called from the callback would presumably not be part of the callback, though
> any yield methods would not end it.

Agreed, we can make the spec more clear.

> Do we need to explicitly state that user agents may arbitrarily set a max-limit
> (> 1000) to the length of the BufferSize due to memory concerns?
> If so, should setResourceTimingBufferSize return the size it actually set?

We discussed this in today's call. We all agree that the UA should recommend a 1000 entries rather than require it. The UA can determine the buffersize - e.g., mobile browsing case. setResourceTimingBufferSize should return the maximum limit that UA supports.

> Should the functions throw invalid paramater exceptions if given bad data?

We agree.
Received on Wednesday, 30 March 2011 21:31:24 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:30 UTC