Enable namespace-based subscription for mark / measure

[spanicker]

(feel free to dup if this issue has been discussed previously)
A lot of different parties -- such as Ads, frameworks etc -- are now adding mark & measure to timeline. It is spammy to receive all the marks added by everyone on the timeline.

Currently developers have to discover and maintain a list of name prefixes to ignore.
(for instance Google Ads caused some ripples with adding "goog" prefixed marks affecting large number of sites)

Instead, it would be great if marks & measures could be namespace'd and developers could subscribe to specific namespaces.

@pmeenan @paulirish @nicjansma

[nicjansma]

I like the idea.

Were you envisioning a whole new set of API arguments to accept the optional namespace, or something "built-in" to the mark name?

i.e.

// goes into the 'mysite' namespace
performance.mark("mysite:foo");

// or more declarative
performance.mark("foo", "mysite");

// clearing
performance.clearMarks("mysite:foo");
performance.clearMarks("foo", "mysite");

// might be nice to be able to clear all from a namespace?
performance.clearMarks("mysite:*");

Gets a little clunkier with measure() though.

It seems like the PerformanceTimeline and PerformanceObserver interfaces would still need optional UserTiming-specific arguments to know about namespaces:

// timeline
performance.getEntriesByType("mark", "mysite");
performance.getEntriesByName("mysite:*");

// observer
var observer = new PerformanceObserver(...);
observer.observe({entryTypes: ['mark'], namespace: "mysite"});

[gaearon]

We (React) are definitely interested in this. I'm thinking of always emitting measurements for components by default in DEV, but then this would spam the DevTools for people who aren't profiling React at the moment.

Unfortunately, any prefix makes the tree completely useless in Chrome because you have to zoom in to read any individual item. For now, I'm thinking of using emoji for React measurements:

This way people using PerformanceObserver can still easily filter them while the entries stay legible. However, having a built-in support for namespacing in the API (and having the tools understand it and provide filtering) would be nice.

[eliperelman]

On Firefox OS, we had to do some similar hackery to be able to filter performance entries by application:

performance.mark('appLaunch@clock.gaiamobile.org');

But eventually this would come down to wanting to filter on any kind of custom data. Maybe custom data should be resurrected and then the filter done in the observer?

new PerformanceObserver(list => {
  list
    .filter(measure => measure.data.namespace === 'react')
    .map(measure => doWhatever());
).observe({entryTypes: ['measure']});

[igrigorik]

I believe w3c/charter-webperf#28 will solve all of the above pretty cleanly. Roughly...

• We should allow developers to mint custom events.
• Such events can define own name's, but should have some custom format/prefix to make sure that user-defined events don't conflict with UA define events.
• PerformanceObserver support would automatically fall out of that.
• Downstream consumers can subscribe to any custom event stream, as long as they know the name.

If that sounds reasonable, I propose we close this and move the discussion to the other thread.

[nicjansma]

I like w3c/charter-webperf#28 a lot. The main downside I see to that approach is discoverability.

For example, today, if RUM wants to collect all UserTimings on the page, from every library producing any marks and measures, it's a straightforward getEntriesByType("marks").

If we migrated everyone to creating custom PerformanceEntry objects, RUM wouldn't know whether those "custom" PerformanEntry types should be collected as well. Browser dev tools wouldn't necessarily know if they're appropriate to put in their dev tools timelines, etc.

Moving people to custom PerformanceEntries kinda goes against one of the strong-points of UserTiming, which is when we get everyone producing UserTiming marks/measures, more third parties will be encouraged to consume/display/measure/aggregate them.

Unless... those custom PerformanceEntries are all subclasses of PerformanceMark/Measure?

[igrigorik]

A lot of different parties -- such as Ads, frameworks etc -- are now adding mark & measure to timeline. It is spammy to receive all the marks added by everyone on the timeline.

vs.

If we migrated everyone to creating custom PerformanceEntry objects, RUM wouldn't know whether those "custom" PerformanEntry types should be collected as well. Browser dev tools wouldn't necessarily know if they're appropriate to put in their dev tools timelines, etc.

One of these has to give.. Right now we're on a blacklist model, which is what motivated this thread. By moving to a whitelist model (you need to know what you want), you reduce the noise, but trade it off against missing what you don't know.

FWIW, I think well known lists would emerge pretty naturally -- e.g. React team can declare their names, which everyone can subscribe to, and so on.

[nicjansma]

Maybe with w3c/charter-webperf#28 we could have a way of enumerating all custom PerformanceEntry types?

That way if RUM wants to have knowledge of all things, it looks at the registry and queries each individually?

[igrigorik]

Yeah, that's a plausible solution. However, that's also time dependent solution.. someone has to emit the record before we know about it, and there are no guarantees that they will do so ever again. Let's note it on that thread and move the discussion there.

Any objections to closing this one?

[nicjansma]

None from me

[spanicker]

None from me either.

[igrigorik]

👍

Let's continue discussion in w3c/charter-webperf#28.