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