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

Re: [NavigationTiming] few comments

From: Zhiheng Wang <zhihengw@google.com>
Date: Tue, 22 Mar 2011 23:39:39 -0700
Message-ID: <AANLkTin2Cs99B7n-aNrpmszcy4zTxM_6FsYfdGRRgzfj@mail.gmail.com>
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>
    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
>        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
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

Received on Wednesday, 23 March 2011 06:40:08 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:30 UTC