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 <[email protected]
<mailto:[email protected]>> 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
