- From: Przemysław Pietrzkiewicz <ppi@google.com>
- Date: Tue, 1 Jul 2014 16:59:54 +0200
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: public-web-perf@w3.org
- Message-ID: <CAMqrY-s6WSzkUJNyvh5P_4PpuWLFooue=5N7=x_1UT26TMXcug@mail.gmail.com>
Hello, Please find the replies inline below. 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? 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. > 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? Because when the prompt is being displayed it's not determined if the navigation will happen. As noted above, I assume the reason why the beforeunload prompt is mentioned in the current wording is because the navigation is assumed to happen when the user confirms the prompt. > > 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. I think it does match the goal - which is to measure the user perceived time of the *browser navigation*. This can't involve (possibly complex) script logic that causes the navigation to happen in response to an earlier user action. In the example being discussed here, the 2s of delay happens before the navigation. [1] https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/NavigationTiming/timing-overview.png Cheers, Przemek
Received on Tuesday, 1 July 2014 15:00:26 UTC