Re: Ready indicator

Hey Nic,

That PerformanceMark looks like it would solve all the use cases I have
been thinking about, but I have contentions over the Recommended Mark Names
[1]. First, the names recommended are using an underscore separated naming
convention, and it seems inconsistent with the timestamps located in
performance.timing. In fact, in the same document it mentions throwing a
SYNTAX_ERROR if using a name that clashes with any of the standardized
marks in performance.timing. I would rather move to see all the entries be
recommended camel-cased to be consistent with the existing entries.

Also, using the prefix "mark" in each of the Recommended Mark Names is
redundant, as all of the entries would inherently be marks.

All-in-all though, it's very good to see this initiative line up so
similarly with some of the internal work-arounds we have been doing at
Mozilla. [2]

[1] www.w3.org/TR/user-timing/#ut-standard-mark-names
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=996038

Thanks,

*Eli Perelman*
Software Engineer, Firefox OS

On Sun, Oct 12, 2014 at 11:24 AM, Nic Jansma <nic@nicj.net> wrote:

>  That was the intent of the "mark_fully_loaded" "standardized" timestamp:
> http://www.w3.org/TR/user-timing/#dom-performance-mark
>
> - Nichttp://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>
> 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
>>
>
>
>