Re: Ready indicator

That was the intent of the "mark_fully_loaded" "standardized" timestamp:
http://www.w3.org/TR/user-timing/#dom-performance-mark

- Nic
http://nicj.net/
@NicJ

On 10/11/2014 3:42 AM, Yoav Weiss wrote:
> Isn't this use case covered by the User Timing API 
> <http://www.html5rocks.com/en/tutorials/webperformance/usertiming/>? 
> (with perhaps adding some convention on a common "web app loaded" event)
>
> On Fri, Oct 10, 2014 at 7:08 PM, Eli Perelman <eperelman@mozilla.com 
> <mailto:eperelman@mozilla.com>> wrote:
>
>     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
>
>