Re: navigationStart and the actual start of the navigation

On 7/1/14, 10:25 AM, Przemysław Pietrzkiewicz wrote:
> What do you think should be the goals here?

I have no idea.  I have no particular use cases for navigation timing 
myself; you should presumably ask the people who authored the spec and 
the ones who contributed use cases.  Or check the list archives, of 
course, since I'm pretty sure this was discussed.

> I assume that "navigationStart" should reflect the entire navigation time as perceived
> by the user, including things beyond the control of the page. Developers
> that want to exclude the things beyond their control have the other
> attributes of PerformanceTiming at their disposal.

Do they?  Which ones?

> By including the early, browser-incurred delays in navigationStart,
> we're giving better visibility to the developer, possibly indicating
> that it is (sadly) the things beyond their control that make the
> navigation they care about slow (e.g. because starting new browser
> context was slow).

In that case, I don't see why we'd want to exclude the time it takes 
users to respond to beforeunload prompts.  Why are these two situations 
different?

> In the case of a click handler that does 2s worth of computation and
> sets location, I would assume that it is the location set that gets
> reported, as UA is not in position to trace the chain of interactions
> that caused the navigation to be eventually triggered.

That doesn't match your stated "user-perceived delay" goal, and I'm not 
sure I follow your "UA is not in a position" thing, honestly.

-Boris

Received on Tuesday, 1 July 2014 14:37:29 UTC