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.


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

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

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

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