Re: navigationStart and the actual start of the navigation

Hello,

Boris, thanks for the clarifications! So strictly speaking the current
wording is well-defined for all cases except for the initial about:blank
(even if the bit about "no previous document" is misleading).

I'm interested in measuring the navigation time for a navigation that
requires a new browsing context. The delay of spawning a new renderer that
that brought me here is not represented in the records when navigating in a
new browsing context, but it *is* represented in navigationStart when the
navigation takes place in an existing browsing context.

So the question is - how the spec should work for navigations in new
browsing contexts? Recording the time of transitioning from about:blank to
the actual target seems a bit late in the process. Moreover, if the user
agent is smart, it could conceivably start requesting the target resource
immediately (i.e. when it decides to create the browsing context), way
before the browsing context is ready and transitions from about:blank.
Under the current spec, it would yield redirectStart (and friends) with
earlier timestamps than navigationStart.

Do you think it would be reasonable to consider a wording that would:
- keep the current behavior for navigations in existing contexts
- record the time when the UA starts creation of new browsing context for
navigations that require new browsing contexts

?

Arvind, thanks for your input! I think we're on the same page - I
understand that we want the navigationStart to be recorded early, and
subsequent attributes allow to take the things the consumer is not
interested in out of the picture.

Cheers,
Przemek


On Tue, Jul 1, 2014 at 9:10 PM, Arvind Jain <arvind@google.com> wrote:

> The goal of the spec was to get developers full insight into how long
> it took the page to load once the browser started to navigate to the
> page as well as how much the user perceived latency was.
>
> So ideally, it'd be good to report the time starting from when the
> user clicks, and report the breakdown (time it took to unload the
> previous page, create the new tab etc.).
>
> Just like spawning renderer takes time, there are other situations
> e.g. the network on the phone may be down and you have to bring it up.
> In navigation timing 2, we added a metric called
> linkNegotiation{Start|End} to capture that. In that case, responseEnd
> - navigationStart would capture the total time the user waited and the
> developer can subtract the linkNegotiation time from it if he wants
> to.
>
> So if possible, it would be good to have navigationStart refer to when
> the user expresses intent to navigate by clicking and then track the
> time to unload previous document, bring up the network and start the
> renderer in the included metrics. I'm not sure how to capture it.
>
>
>
> On Tue, Jul 1, 2014 at 9:30 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> > On 7/1/14, 12:27 PM, Boris Zbarsky wrote:
> >>
> >> The user clicks a button.
> >
> >
> > Mouse button, that is.  After which there is OS and UA event loop lag
> before
> > DOM click event dispatch happens.
> >
> > -Boris
> >
>
>