RE: [Resource Timing] Spec feedback

Thanks for pointing out those inconsistencies.  To be compatible with Navigation Timing, the intention of fetchStart is to encompass the timings for the last resource fetched, if there were redirections.  As you suggest, in this case, startTime would be equal to redirectStart, as opposed to fetchStart.

We will update the spec with this suggestion as well as your previous email's suggestions.

- Nic

From: public-web-perf-request@w3.org [mailto:public-web-perf-request@w3.org] On Behalf Of James Simonsen
Sent: Monday, August 22, 2011 6:08 PM
To: public-web-perf
Subject: Re: [Resource Timing] Spec feedback

On Thu, Aug 18, 2011 at 12:52 PM, James Simonsen <simonjam@chromium.org<mailto:simonjam@chromium.org>> wrote:
I've been looking at implementing this again and made notes of some things we might want to change in the spec. Let me know what you think.

"The startTime attribute must return..."

  *   Why doesn't this just return fetchStart? I'd like the range [startTime, startTime + duration] to encompass all of the values in the struct (except for the zeroed out ones). As it is now, fetchStart may occur before startTime.
After reading the processing model more carefully, I think the actual problem is that there's a disconnect between the description and the processing model.

Based on fetchStart's description, which links to the HTML5 spec, we should include redirects in fetchStart. But, in the processing model, it says we should reset fetchStart after a redirect. One of those should be fixed. I think the processing model is correct. That matches the diagram too.

We still need to update the processing model though. It says, "Otherwise, immediately before a user agent starts the fetching process, record the current time as fetchStart." Since the fetching process includes redirects, this only ever happens once per resource.

We might want to include startTime on the diagram too. It'd help make it clear what the distinction is between fetchStart and startTime.

James