- From: Przemysław Pietrzkiewicz <ppi@google.com>
- Date: Wed, 23 Jul 2014 19:07:57 +0200
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: "Reitbauer, Alois" <Alois.Reitbauer@ruxit.com>, "public-web-perf@w3.org" <public-web-perf@w3.org>
- Message-ID: <CAMqrY-sGkcFz=f3ecCyQy1ix56Xpe3HDwMF07DJ4V58aM8JU0A@mail.gmail.com>
Thanks, Boris, and apologies for the delay. On Thu, Jul 10, 2014 at 5:35 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote: > 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. Agreed; I think that for some applications "most" will not be good enough though. Maybe recording navigationStart earlier but providing new intermediate points so that it's possible to exclude the onbeforeunload event if needed would be reasonable? > > > 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. Right. So based on the discussion so far, would it make sense to aim for a change that would: - record "navigationStart" at the time that the browser starts to navigate - details of the wording would need to be figured out, but we would want this to happen before any of: onbeforeunload, finding the frame to navigate or creating the new tab - provide new intermediate attributes for the beginning and the end of onbeforeunload ? New intermediate records should probably be available only on same site navigations, following suite of the exisiting unloadEventStart / unloadEventEnd attributes. Wdyt? PS I'm ooo until the 4th of August with limited email access, apologies for any inconvenience. Cheers, Przemek
Received on Wednesday, 23 July 2014 17:08:30 UTC