Re: [User Timing] Integration with Performance Timeline

> In particular, some developers may only be interested in measuring their
> custom scenarios that they've instrumented via marks and measures and not
> all other PerformanceEntries.  Uploading just the measure times may be in
> the few bytes range vs. uploading a full list of Navigation Timing,
> Resource Timing, and User Timing in their full, verbose JSON object format.
> Even if using getEntriesByType(“mark”), a developer may truly only be
> interested in the mark/measure data and not the additional data like
> startTime and entryName.
>

That's true for all of our PerformanceEntries. For instance, we don't
provide an API to get just the duration of the Resource Timing entries.
Instead, we let users filter out the data they don't want after the fact.

I don't see why User Timing is a special case that requires its own custom
interface. Now that we have performance.now(), User Timing is not a
necessary feature. It can be implemented entirely in JavaScript, perhaps as
a jQuery extension or the like. The only value we can add in the browser is
to integrate it into the Performance Timeline. That should be our focus.


> The getMarks() interface also "groups" same-named marks into a single
> entry, with a name:[timestamp array] association, whereas getEntriesByType
> would return a new object for every mark timestamp.
>

Likewise with Resource Timing. Each load of the same resource gets its own
entry.

One of our goals should be to have a consistent experience. As long as its
consistent, it'll be easy for developers to use all of our timing specs.
It'll only lead to confusion if we continue down the path of providing
different APIs for each timing spec. We've already made this mistake by
having a separate API in Navigation Timing v1, we shouldn't do it again.

****
>
> As Pan mentioned, getMarks and getMeasures return marks and measures
> according to the order of when they were added, whereas getEntriesByType
> and getEntriesByName return entries sorted according to chronological order
> defined by startTime. I believe there is value in both looking at the
> entire timeline in the correct timeline order and looking at just the
> marks/measures in the order you added them.
>

What if I want alphabetical order? Or maybe I only want to see the most
recent marks, so I want it reverse sorted by end time. Or maybe I just want
to see which are the slowest, so I want it sorted by duration. Should we
add APIs for all of these too? They also sound valuable.

My point is, it doesn't make sense for the browser to provide all of these
options. We can't predict all the possible ways this data could be useful
and provide interfaces for them. We should just surface the data in a
consistent way and let the consumers come up with cool ways to slice and
dice the data.

James