- From: Zhiheng Wang <zhihengw@google.com>
- Date: Fri, 25 Mar 2011 15:39:12 -0700
- To: Tony Gentilcore <tonyg@google.com>
- Cc: Olli@pettay.fi, Olli Pettay <Olli.Pettay@helsinki.fi>, public-web-perf@w3.org, Nic Jansma <njansma@microsoft.com>
- Message-ID: <AANLkTimVbhuy4CK6xhNKEvKdrU8Oc-JAO8nyJ0tz77P5@mail.gmail.com>
On Tue, Mar 22, 2011 at 11:39 PM, Zhiheng Wang <zhihengw@google.com> wrote:
> Great comments indeed.
>
> On Sat, Mar 19, 2011 at 3:51 PM, Tony Gentilcore <tonyg@google.com> wrote:
>
>> > So, here are few comments.
>>
>> Thanks for taking the time to do a detailed review. Very useful.
>>
>> > (1 Introduction)
>> > Minor nit, "For example, the following Javascript shows the time it
>> > take to fully load a page: "
>> > That is not quite true. If the first package from the server happens
>> > to contain only "<html><head>", the script is just measuring some
>> > random part of the page load.
>> > The explanation clarifies that, but still, saying "shows the time it
>> take to
>> > fully load a page" is just misleading.
>>
>> +1
>>
>> May I suggest this text:
>> "For example, the following Javascript shows a naive attempt to
>> measure the time it takes to fully load a page:"
>>
>
> yup, I will fix the text here.
>
>
>
>>
>> > "This interface does not include an attribute to represent the
>> completion of
>> > sending the request, e.g., requestEnd.
>> > Completion of sending the request from the user agent does not always
>> > indicate the corresponding completion time in the network transport,
>> which
>> > brings most of the benefit of having such an attribute.
>> > Some user agents have high cost to determine the actual completion
>> time
>> > of sending the request due to the HTTP layer encapsulation.
>> > "
>> > These sound partially like implementation issues. Why is some
>> > implementation issue affecting a spec this way?
>> > Could requestEnd, even if just the user agent part of it - not network
>> > layer, be still useful for POST?
>>
>> Earlier versions of the spec and Chrome implementation had a
>> requestEnd marker that would be useful for POSTs (or even GETs with
>> large Cookies). It was later removed for reasons discussed in this
>> thread:
>> http://lists.w3.org/Archives/Public/public-web-perf/2010Aug/0006.html
>>
>> Not sure what others think, but I'd have no problem with seeing it
>> resurrected.
>>
>
> @Nic, what's your thought from IE's perspective?
>
>
To follow up. The WG had some discussion about requestEnd during Wed's
call
and agreed that requestEnd measured from the user agent's perspective is
often
too obfuscated to provide useful information in practice. So we will not
include it in
the current draft.
cheers,
Zhiheng
>
>
>>
>> > "TYPE_RESERVED: Any navigation types not defined by values above."
>> >
>> > Since types are quite limited and underspecified, all the script
>> > initiated loads would be TYPE_RESERVED. So would all the form
>> > submissions. Is that what is really wanted? Seems like at least Chrome
>> > uses TYPE_NAVIGATE also for other things than just "navigation started
>> > by clicking on a link or entering the URL in the user agent's address
>> bar."
>> > But in which all cases it uses that type, I dunno.
>> > And what does IE9 do?
>>
>> The types are limited because the purpose of this field is to indicate
>> types that typically have very distinct page load time
>> characteristics. For instance a back/forward is typically much faster
>> than an initial navigation.
>>
>> But I agree the types are underspecified. My understanding is that
>> TYPE_RESERVED should never be returned. I'd support an update that
>> clarifies that form submissions and script initiated navigations fall
>> under TYPE_NAVIGATE. I'd also support removing TYPE_RESERVED
>> altogether.
>>
>> > "Client-side redirects, such as those using the Refresh pragma
>> directive,
>> > are not considered HTTP redirects or equivalent by this spec. In those
>> > cases, the type attribute should return appropriate value, such as
>> > TYPE_NAVIGATE, as if in non-redirect navigation."
>> > This is too vague. It must be specified when to use TYPE_NAVIGATE and
>> > when perhaps TYPE_RELOAD and when something else.
>> > Using TYPE_NAVIGATE would actually violate its current definition
>> > "navigation started by clicking on a link or entering the URL in the
>> user
>> > agent's address bar."
>>
>> Another good point. This is important.
>>
>> Based on my understanding of the intent of the spec, I propose
>> removing " and record the current navigation type in
>> window.performance.navigation.type if it has not been set" from 4.5.2
>> and inserting the following new steps between 4.5.2 and 4.5.3:
>>
>> 4.5.3. If the navigation algorithm[1] was invoked either as a result
>> of a meta refresh[3], the reload() method[4], or other action that
>> behaves the same as the reload() method[4], then let navigation-type
>> be TYPE_RELOAD.
>>
>> Else if the navigation algorithm[1] was invoked as a result of
>> history traversal[2], let navigation-type be TYPE_BACK_FORWARD.
>>
>> Otherwise, let navigation-type be TYPE_NAVIGATE.
>>
>> Then in section 4.3, the type attribute must return the current value
>> of the navigate-type variable as defined in section 4.5.3.
>>
>> [1] http://dev.w3.org/html5/spec/Overview.html#navigate
>> [2] http://dev.w3.org/html5/spec/Overview.html#traverse-the-history
>> [3]
>> http://dev.w3.org/html5/spec/Overview.html#attr-meta-http-equiv-refresh
>> [4] http://dev.w3.org/html5/spec/Overview.html#dom-location-reload
>>
>>
> Instead of enumerating/predicting all the possible navigation
> types, TYPE_RESERVED
> is meant to be a catch-all type (to replace TYPE_OTHERS in the original
> draft) while we
> outline some of the common ones that are likely to be used in latency
> analysis. Some
> consistency is lost between edits.
>
> I agree that we need to be more specific about the reloading cases
>
> thanks,
> Zhiheng
>
Received on Friday, 25 March 2011 22:40:08 UTC