Re: Ready indicator

Hi Eli!

In hindsight, I would agree with both of your recommendations.

At this point though, with UserTiming being a W3C Recommendation, I 
think that changing the names would bring confusion.  They're also only 
seen by developers.

If there are any additional "standard" marks you can think of that would 
be useful, please let us know as well.

Thanks,

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

On 10/12/2014 1:16 PM, Eli Perelman wrote:
> 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 
> <http://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 
> <mailto: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
>
>     - 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
>>
>>
>
>