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

RE: [NavigationTiming] incorrect description for requestStart

From: Jatinder Mann <jmann@microsoft.com>
Date: Thu, 26 May 2011 17:13:19 +0000
To: Zhiheng Wang <zhihengw@google.com>, Jason Duell <jduell@mozilla.com>
CC: Christian Biesinger <cbiesinger@gmail.com>, public-web-perf <public-web-perf@w3.org>
Message-ID: <EE4C13A1D11CFA49A58343DE361B0B0406852304@TK5EX14MBXC254.redmond.corp.microsoft.com>
Zhiheng,

We have reviewed the changes made to Navigation Timing. These changes look good. I have opened ACTION-34 - Update Resource Timing spec with the same requestStart fix made in Navigation Timing spec on you to make these changes to Resource Timing also.

Thanks,
Jatinder

From: public-web-perf-request@w3.org [mailto:public-web-perf-request@w3.org] On Behalf Of Zhiheng Wang
Sent: Tuesday, May 24, 2011 4:37 PM
To: Jason Duell
Cc: Christian Biesinger; public-web-perf
Subject: Re: [NavigationTiming] incorrect description for requestStart

   FYI, the WD is now updated to make more sense out of the http cache operations.

    1) Section 4.2, skip mentioning the http cache checking. It only makes sense for requestStart to include
the checking of http cache if it's a cache hit.
    2) In processing model step 8, if it's an http cache hit, go to the step of recording requestStart directly and
leave domain lookup and connection time as fetchStart.

cheers,
Zhiheng

On Fri, May 20, 2011 at 3:31 PM, Zhiheng Wang <zhihengw@google.com<mailto:zhihengw@google.com>> wrote:

On Thu, May 19, 2011 at 5:49 PM, Jason Duell <jduell@mozilla.com<mailto:jduell@mozilla.com>> wrote:
I'm also a bit confused by which/when timings should be set in the case of a cache hit from the regular HTTP cache.  The spec notes that

"Checking and retrieving contents from the HTTP cache [RFC 2616] is part of the fetching process. It's covered by the requestStart, responseStart and responseEnd attributes."

Looking at steps 8-15 in the processing model for an HTTP cache hit:
-  step 9: at least for Mozilla, no DNS lookup is required to look for a cache hit, so goto step 11
- step 11: makes it sound like we should be recording connectionStart/End for a cache hit, which doesn't make much sense?

   great catch. Given that step 7 already set domain and connection related value to the same as fetchStart,
it might be sufficient to modify step 11 as the following?

   "If no transport connection is used to fetch the resource, go to step 13. If a persistent transport connection is used
to fetch the resource, <the rest of the paragraph>".

   An alternative is to modify step 8 to include http cache, i.e.,
  " If the resource is fetched from the relevant application cache or HTTP cache or local resources, go to step 13."
But I would like to see if this works fine with other user agents. Nic and Tony, any thought?

cheers,
Zhiheng

- step 13: I assume we set 'requestStart' just before we start looking at the HTTP cache?
- step 14/15: seem to map sensibly onto first/last bytes of reply serviced from cache.

I'd propose we drop the connectionStart/End timing for cache hits, and generally make the language clearer about what happens in the processing model in the cache hit case.

Jason Duell
Mozilla


On 05/19/2011 05:37 PM, Christian Biesinger wrote:
On Thu, May 19, 2011 at 5:33 PM, Christian Biesinger
<cbiesinger@gmail.com<mailto:cbiesinger@gmail.com>>  wrote:
Hi,

I just noticed a bug in the description for requestStart (Thanks jduell):
This attribute must return the time immediately before the user agent starts requesting the current document. It is set prior to checking HTTP cache.
 From what I remember from the discussions and from the timeline below,
the "HTTP cache" sentence should be removed here, because this
attribute refers to the time immediately before the UA starts
write()ing to the socket. Otherwise, this would be identical to
fetchStart (which does have similar cache wording).
Also, can we clarify what "local ressources" are? Probably things like file:///<file:///\\>?

-christian
Received on Thursday, 26 May 2011 17:13:48 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 May 2011 17:13:49 GMT