Re: [ResourceTiming] Resource timing details

On Tue, May 17, 2011 at 1:31 PM, Tony Gentilcore <tonyg@google.com> wrote:

> 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.
>

   Just to keep this topic alive. :-)

   One potential use case for ResourceTiming: I can add something like
setTimeout("diagnose()", 10000) to a page.
If onload is not fired after 10 seconds, diagnose() can identify the
blocking resource using the ResourceTiming structure.
In that case, knowing approximately where we are in terms of fetching the
resource is important.

   So what I would propose is:
  * when resource is enqueued for fetch, create and add the
PerformanceResourceTiming object with everything set to 0 except
resourceStart, which is set to the current time.
  * set fetchStart when the fetching starts.
  * rest of the timing attributes are set at responseEnd.

cheers,
Zhiheng








>
> 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
>