Re: User Timing Mark Name for "Critical Content Loaded"?

At least for what I was planning to do with it it wouldn't alter any
behavior.  We (and I expect most browsers) track aggregate field metrics
for a bunch of technical metrics to track our performance and guide our
optimization work.  None of the standard technical measurements really mean
anything for the user experience (onload, DOM Content Loaded, etc).  A lot
of sites have their own custom metrics that they track that does better tie
to the user experience and most that do have a core "this is the user
experience time for this operation".  The time to first tweet and time to
first pin were concrete examples that I know of but just about every major
web property has their own.

What I'd like to do is to be able to collect that in a standard way so that
when we make optimization trade-offs we take the applications actual
experience metrics into account.  That does mean that it will impact
decisions that we make about how the browser works but not in the context
of that specific page or page load.

The standardization for reporting tools is just an added bonus.

On Wed, Jun 24, 2015 at 5:06 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> I still think that the bigger question isn't what string value to use,
> but whether it is appropriate to say that certain "mark" names have
> semantic meaning or not.
>
> The way that the spec currently works, from my understanding, is that
> it says "you can use whatever name of a mark you want. The names have
> whatever meaning you assign to them. Except if you use names X, Y or
> Z, those have a very specific meaning and will cause A, B and C to
> happen.".
>
> Another way to put this is that it feels weird that we have an API
> which allows a page to add page-defined marker to a timeline. Except
> that if you give those marker a specific name, it affects when the UA
> render the page, which is a functionality completely unrelated to the
> timeline (other than that both functionalities involve "time").
>
> / Jonas
>
>
> On Tue, Jun 23, 2015 at 11:04 PM, Eli Perelman <eperelman@mozilla.com>
> wrote:
> > I raised a question back in October [1] about the consistency and
> redundancy
> > of the "Recommended" mark names, and while in hindsight it probably would
> > have been a good idea to camel-case the recommended names and remove the
> > word "mark", the spec had already reached recommendation. With Firefox
> OS I
> > decided to break away from the recommended mark names in order to cover
> our
> > use cases, and move ahead with the marks that are in place now. If I
> recall
> > the rest of the thread, we proposed that the Recommendation be revised,
> but
> > that didn't go anywhere. We had searched Chrome source back at the time
> and
> > couldn't find any occurrences of the inconsistent markers and other
> vendors
> > were not using them as well, which solidified our decision to continue on
> > with what we considered the right way was.
> >
> > My preference is still that we either work to define better "Recommended
> > Markers" that are more consistent and revise that section, rather than
> just
> > changing the names around to make them fall in line with what is
> currently
> > spec'd.
> >
> > Thoughts?
> >
> > [1]
> http://lists.w3.org/Archives/Public/public-web-perf/2014Oct/0035.html
> >
> > Eli Perelman
> > Mozilla
> >
> >
> > On Tue, Jun 23, 2015 at 10:37 AM, Philippe Le Hegaret <plh@w3.org>
> wrote:
> >>
> >> On 06/23/2015 01:07 PM, Patrick Meenan wrote:
> >>>
> >>> Awesome.  navigationLoaded looks to be exactly what I was describing.
> >>> The others look pretty similar to the ones defined in the spec but with
> >>> different names - any reason in particular (or were they created before
> >>> the named ones in the spec existed)?
> >>>
> >>> I'd be happy to track the same named marks in Chrome though it would be
> >>> nice if we could get the spec and the Mozilla names to converge.
> >>
> >>
> >> I added
> >>  https://github.com/w3c/user-timing/issues/5
> >>
> >> Philippe
> >
> >
>

Received on Wednesday, 24 June 2015 23:29:27 UTC