- From: Przemysław Pietrzkiewicz <ppi@google.com>
- Date: Tue, 1 Jul 2014 16:25:15 +0200
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: public-web-perf@w3.org
- Message-ID: <CAMqrY-urKDGhpsevVLYT+gGrk2rR8XCfDdoJ5fbCJ4u97MVWsw@mail.gmail.com>
What do you think should be the goals here? 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. 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 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. Does that sound reasonable? Cheers, Przemek On Tue, Jul 1, 2014 at 3:24 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote: > On 7/1/14, 7:41 AM, Przemysław Pietrzkiewicz wrote: > >> "This attribute must return the time immediately after the user agent >> finishes prompting to unload the previous document. If no such prompt is >> displayed, this attribute must return the time of the event that >> triggered the navigation." >> > > So if I have a click handler that does 2s worth of computation and then > sets location, will the navigation start be at the location set or at the > event dispatch point in time? > > > I think a reasonable goal for the parameter would be to capture the >> duration of the navigation *as perceptible by the user* (to the extent >> of feasibility, of course). If we exclude things like locating the >> subframe to navigate or spinning up new browsing context, we can have >> navigations that feels sluggish but are reported as fast. >> >> What do you think? >> > > I think it really depends on the goals here. Are we trying to report > things that are at least possibly under the control of the page being > loaded, or not? > > Is there a fundamental conceptual difference between a beforeunload > handler that does a 3s sync XHR to save data and a click handler on anchors > that does a 3s sync XHR to save data? Does it matter whether the click > handler does this before or after setting window.location? > > -Bori >
Received on Tuesday, 1 July 2014 14:25:42 UTC