Re: navigationStart and the actual start of the navigation

How about we set the goal to measure the "user perceived latency" and
provide as much breakdown of it as possible? That's always been the
goal of Navigation Timing.

To achieve that, we want to start recording timings right after the
user tells the system his intention to navigate. And we'd capture
steps like time to unload, bring up network, create the new tab etc.

Is that a clear goal that we can agree on?

Arvind


On Wed, Jul 2, 2014 at 9:32 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 7/2/14, 12:21 PM, Przemysław Pietrzkiewicz wrote:
>>
>> I recognize these are all important questions, but I don't see why these
>> need answering in this case.
>
>
> You're making the argument that the current definition of navigationStart is
> not useful and hence we should change the definition.
>
> I'm saying we should decide what the new definition should capture and then
> figure out how to define it, instead of just making up something ad hoc that
> addresses the one thing you care about, and even that only in some cases but
> not others.
>
>
>> Would you agree that it makes sense to record the navigationStart early
>> (possibly adding new attributes for intermediate steps some consumers
>> would not be interested in)?
>
>
> I don't have a strong opinion on this, actually.  I don't think it would
> particularly hurt to do it.
>
>
>> If yes, isn't moving the navigationStart for navigations in new browsing
>> context to the time the context is created an improvement? Why does it
>> require revisiting the definition for navigations in existing browsing
>> contexts?
>
>
> Because now you have inconsistent behavior depending on where a load happens
> to be targeted.
>
> -Boris

Received on Wednesday, 2 July 2014 17:04:01 UTC