- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Tue, 01 Jul 2014 11:23:56 -0400
- To: Przemysław Pietrzkiewicz <ppi@google.com>
- CC: public-web-perf@w3.org
On 7/1/14, 10:59 AM, Przemysław Pietrzkiewicz wrote: > Every other attribute of PerformanceTiming is supposed to happen not > earlier navigationStart as per [1]. So I'd assume that all of the other > parameters exclude more of the events of the navigation timeline. That's correct, but there is no attribute that corresponds to "after the previous page has finished doing whatever it's doing" apart from navigationStart. > Because when the prompt is being displayed it's not determined if the > navigation will happen. So what? If you care about the _user perceived_ latency (and it's not clear to me that that's the goal of this API as it stands), then that's what you should measure. If the navigation never happens, there is no problem; nothing gets that navigationStart value from before the dialog came up. > I think it does match the goal - which is to measure the user perceived > time of the *browser navigation*. Why do users care about this? > This can't involve (possibly complex) > script logic that causes the navigation to happen in response to an > earlier user action. I don't think users care about the difference, or indeed understand it, between a navigation taking 2s extra because the browser takes a long time to create a new window or because the page didn't respond to their click for 2s because it was mining bitcoins off the click event handler or because the browser spent 2s running other parts of the event loop before even delivering the click to the web page.... -Boris
Received on Tuesday, 1 July 2014 15:24:25 UTC