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

Re: [NavigationTiming] few comments

From: Tony Gentilcore <tonyg@google.com>
Date: Sat, 19 Mar 2011 15:51:35 -0700
Message-ID: <AANLkTi==31f-XgsRDuW5dd2Jm_Mbu=ovzi2kYDSUetDS@mail.gmail.com>
To: Olli@pettay.fi
Cc: Olli Pettay <Olli.Pettay@helsinki.fi>, public-web-perf@w3.org
> 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:"

> "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.

> "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
Received on Saturday, 19 March 2011 22:52:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 19 March 2011 22:52:37 GMT