Re: navigationStart and the actual start of the navigation

On 7/10/14, 8:29 AM, Przemysław Pietrzkiewicz wrote:
> The thing we're missing, is the "prompting to unload" routine, which may
> or may not include displaying the beforeunload prompt and waiting for
> the user decision. I can see why the spec leaves this step out - as per
> Arvind's statement of the goals, we want to capture the "user perceived
> latency", and one could argue that the time the user decides whether to
> navigate is not "navigation latency".

Most beforeunload handlers don't actually prompt the user in practice. 
They just do a bunch of work.

> Starting the timer after the beforeunload handler (but before unload
> handlers) seems to be a compromise between the goal of the spec and the
> practical issue that the beforeunload step might or might not contain
> big delays not perceived as the navigation latency. Does anyone feel
> that this should be revisited?

I think that _if_ we're trying to measure user-perceived delay, it 
should be.  Note that I suggested earlier in this thread as specific way 
this could be changed to make it better.

> On the other hand, the way that navigations in new browsing contexts are
> captured does not comply with the goal seemingly by mistake, not in
> result of any conscious trade-off. The time needed to bring up new
> browsing context clearly is part of the latency perceived by the user.

So is the time needed for the page to process the initial click event 
(which is also not included right now), the time to locate the right 
browsing context when the navigation will happen in an existing browsing 
context (this can be pretty significant on pages with lots of iframes; 
I've timed it in a few cases and it can be much slower than just 
creating a new browser tab depending on the page markup), etc.  Again, 
if the goal is to measure user-perceived latency we should work on doing 
that, but then we should try to actually measure user-perceived latency.

-Boris

Received on Thursday, 10 July 2014 15:36:23 UTC