- From: Zhiheng Wang <zhihengw@google.com>
- Date: Tue, 22 Mar 2011 23:39:39 -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: <AANLkTin2Cs99B7n-aNrpmszcy4zTxM_6FsYfdGRRgzfj@mail.gmail.com>
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? > > > "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 Wednesday, 23 March 2011 06:40:08 UTC