- From: Eli Perelman <eperelman@mozilla.com>
- Date: Fri, 10 Oct 2014 12:08:49 -0500
- To: public-web-perf@w3.org
- Cc: Ehsan Akhgari <ehsan.akhgari@gmail.com>
- Message-ID: <CAJ3X4n_fa+Ji2ZjGmmKywhedv1cCkM2-3nvsxRfRM9FWHQ0KPA@mail.gmail.com>
Hello, In my experiences working on tooling for performance on Firefox OS, I have run into a difficult situation in timing the launch time of various applications. These applications are built using Web-standard technologies, e.g. JavaScript, CSS, and HTML (as such I may use app and site interchangably). In order to effectively measure the amount of time an application took to launch, I would need to know at which moment the application is loaded. Using standard web technologies in the past, we would often rely on indicators of window load or the last tick of the event loop to determine that everything has been completed, but unfortunately in today's world of dynamic loading, this just isn't deterministic. There is no reliable way to *infer* the loading time of an application, or any website for that matter. Each instance has the power to defer loading of all, some, or none of their assets. The window load event does not represent a state in every site or app that deems it usable from a user standpoint. By using an arbitrarily-inferred event for assessing launch performance, engineers are encouraged to defer as much loading as possible in an effort to thwart timing metrics. I believe that if we cannot infer this "ready" state of a site, then the site must have the power to *imply* it. By introducing a performance API where a site can infer what it determines to be its "ready" state, we can provide better value to tooling by making metrics more directly correlated with user-perceived launching. It also has greater use cases outside of just performance tooling, as it can be used as an indicator to engines to possibly optimize the loading of content or even updating its UI in a more intelligent fashion. It would also encourage developers to load assets in the manner that makes sense for them in the development process, and not destroying their workflow for the sake of "boosting the numbers". For Gecko, we believe this would be interesting to implement, and can propose a possible API if this group finds interest in exploring the idea. We would also be interested to discover if there is any prior art in this domain. Thanks, *Eli Perelman* Software Engineer, Firefox OS
Received on Saturday, 11 October 2014 07:27:30 UTC