Re: [Resource Timing] Handling duplicate requests

For case #1, I agree the second shall not be populated.
For case #2, I think the second one should be populated, to align with
resource timing motivation “provide complete timing information related to
resources on a document”. I prefer its resource timing entry:
1)    Phases that before second “resource fetch” initiate should be 0,
2)    Others should be the same to phases in the first timing entry.


2012/11/13 James Simonsen <>

> I wanted to continue the discussion about Resource Timing from the
> workshop...
> The relevant piece of the spec is step 6 of the processing model [1]:
> "If the resource is not to be fetched from the networking layer, such as
> being fetched from an in-memory cache, abort the remaining steps."
> My question is what to do in situations where multiple objects are
> requesting the same resource. There are two important cases:
> 1. The easier case is when two requesters are in the same document.
> 2. The harder case is when two requesters are in different documents.
> In case #1, I think it's clear the first one should "win" and the second
> request is ignored. This should be explicitly called out in the spec.
> Otherwise, technically, the second requester is waiting for the resource
> "to be fetched from the networking layer." That means the current spec _is_
> saying we should have duplicates.
> In case #2, neither one should "win" IMO. The second document may be
> blocked on that resource and it'd be unfortunate if it didn't show up in
> its timeline.
> However, if we do show it in case #2, then the timeline may be confusing.
> For instance, the second document may have been created after the resource
> began fetching, which would mean some of the high res times would be
> negative.
> Another option would just be to show the time spent waiting in each phase.
> So if the DNS lookup occurred before the second document started fetching,
> that'd be 0, but the rest of the fields would be populated.
> Thoughts?
> James
> [1]

Received on Tuesday, 13 November 2012 09:44:11 UTC