Re: [NavigationTiming] requestEnd and reconciliation with server-side measurements

Hi, Rotan,

    You have summarized it well! Most of the points you brought up indeed
contribute to the decision of dropping requestEnd.
And, feedback we received suggests that the cost of finding out a sensible
requestEnd in certain browser might be high, due to
the encapsulation.

    I will seek to give this better documentation in the draft.

thanks,
Zhiheng

On Tue, Jan 18, 2011 at 4:11 AM, Rotan Hanrahan <
rotan.hanrahan@mobileaware.com> wrote:

> According to [1], the requestEnd attribute was removed because it directly
> maps to responseStart, which is reflected in the non-normative illustration
> in [2]. However, as any server-side developer of Web technology will know,
> there is a processing time between the receipt of the final byte of a HTTP
> request and the commencement of the delivery of the response to that
> request. In some cases, the period between request and response can be
> substantial, and this is often what end users perceive as the major factor
> in Web site responsiveness.
>
>
>
> I accept that the technology being described by the Group is client site,
> and that there are factors (such as buffers in the network stack) that make
> it difficult or maybe impossible for the browser client to know when the
> request has been delivered to the server, but it may still be of some
> statistical benefit to know when the last byte of the request left the
> browser (presumably to be appended to the output buffer of the network
> stack).
>
>
>
> It might also be the case that in practice the time between HTTP request
> commencement (requestStart) and complete delivery to the output buffer (what
> I might call requestEnd) is negligible, and therefore the measurement
> between requestStart and responseBegin is sufficient to observe the latency
> of the Web site itself.
>
>
>
> Alternatively, it might be the case that this time between requestBegin and
> requestEnd is not negligible but is predictable/consistent and therefore not
> of any great interest. That is, it can be discounted from subsequent
> statistical analysis.
>
>
>
> Whatever the case, I think the rationale for the omission of requestEnd
> should be included in the document if there is sufficient justification for
> the omission (preferably based on implementation experience), or the Group
> should consider the re-introduction of the attribute if this improves the
> accuracy of the measurement of latency (as seen from the client’s side).
> Currently the absence of any mention of requestEnd in the document merely
> invites questions.
>
>
>
>
>
> Regards,
>
> ____________________________
>
> *Dr Rotan Hanrahan*
>
> Chief Innovations Architect and CTO
>
> MobileAware Ltd
>
>
>
>
>
>
>
>
>
>
>
> [1] http://lists.w3.org/Archives/Public/public-web-perf/2010Oct/0017.html
>
> [2]
> http://www.w3.org/TR/2011/WD-navigation-timing-20110111/#processing-model
>
>
>