Allow performance.measure() to specify optional color parameter, to be used by perf visualizations in devtools

[jakub-g]

There are 2 main uses for performance.measure() AFAICT:

1. Add things to performance timeline to be later retrieved by performance.getEntries*() methods
2. To have the entries visualized in Chrome devtools perf panel.

The visualization part is very powerful for analyzing performance. For that use case, it could be interesting if it was possible to specify the color in which the bars are to be displayed. Right now, Chrome takes random shades of yellow/orange for each bar.

Example usages:

• waiting for resource download could be marked with a different color than actual JS execution, or
• work related to feature1 of the application can be marked with different color than work related to feature2, or
• work that is more critical (core features of the app) or less critical (sending analytics etc.) than other type of work could be marked with different colors to be easily distinguishable. Right now for example in my app, while waiting for important things to be fetched asynchronously, non-important work is happening as the main thread is available. When I look at the Chrome perf panel visualization, it's not immediately obvious where important things are happening vs less important things. I need to zoom in and read the labels to understand that.

[jakub-g]

I know it somehow doesn't feel right to pass the color param to the API which is about measuring things, but I don't know what could be the alternatives. Anyway, having the feature in some form would be pretty interesting IMO.

[npm1]

Hmm I don't think that JS is the correct place to be determining the colors of the marks and measures. To me it seems like this should be a feature request for Chrome DevTools, or any other developer tooling being used to debug. They could potentially add regex filters for entries by name to be colored in a specified color.

[jakub-g]

FWIW it's possible to style console.log. ~It's not in the Console spec~ It is in the Console spec and was implemented by all browsers.

I was not sure what's the best place to ask this, whether in spec or in Chrome bug tracker. The thing is, if it's not in spec, it's unlikely any browser will ship it, as this would collide with potential future extensions of the spec, hence rather risky.

[jakub-g]

They could potentially add regex filters for entries by name to be colored in a specified color.

This is one way to do that, but I find it rather limiting. It's not really portable/scalable (I check on different machine/different version of Chrome etc. and this info is gone); having static filtering only is also limiting; would probably require renaming the labels and/or having complex set of rules in devtools.

One could also imagine for example taking a runtime decision which color to mark something with (for example, different color depending if a task took more time than the budget is) - similar to #25. In this case, regex in devtools does not fit that use case (unless the developer outputs a different label for such measures, to fit the appropriate regex)

[rniwa]

Can't you supply some JSON data on detail and have some convention for DevTool in Chrome? This doesn't seem like something we want to add to the standard.

[bgirard]

I agree that user-timing probably isn't the right place for this to live.

But at the same time some kind of (informal?) standard recommendation documenting what developer tools could do would be helpful rather than relying purely on non-standard behavior. A concrete proposal is that the detail attribute could have a suggested xDevtoolsColor property for devtools to use. This would benefit the ecosystem rather than pushing Chrome only conventions. But I'm not sure where that should live?

When I look at the Chrome perf panel visualization, it's not immediately obvious where important things are happening vs less important things. I need to zoom in and read the labels to understand that.

I have a similar use case where the perf panel is way too crowded. Colors would be helpful. Another useful tool would give a way to tag a mark as belonging to a user defined 'sub-timeline'. Colors and sub-timeline would give a lot of flexibility. In your case you could split critical/non-critical work easily. Here's my use case which is nearly unreadable but would benefit from a colors and sub-timeline informal recommendation:

[jakub-g]

I like the idea of "sub-timelines" as an alternative/complement to colors.

I opened a Chrome DevTools ticket to gather opinions of DevTools folks: https://crbug.com/1057078

[npm1]

I think these are great ideas. It's still not clear to me what's a good way to 'standardize' a solution here, but let's keep this open and eventually this should we discussed in the Web Perf WG. Thanks for filing the Chromium bug, I'll follow up with Chrome DevTools but I know they're pretty swamped in work right now so not sure when this work would occur.

[fshort]

I don't think this belongs in the spec. The example where this was provided in the console spec makes sense because the console is the display of the logging data. Similarly, chrome dev tools would be the display of this data so makes most sense to be provided in chrome (and other browsers).

[yoavweiss]

@mathiasbynens - This seems like a devtools feature request. We discussed this on a recent WG call, and agreed this doesn't seem actionable from a User-Timing perspective, but maybe it's actionable from a devtools/console one. Thoughts?

[mathiasbynens]

I agree this doesn't belong in the spec; it's controlling an implementation detail. Thanks for filing the DevTools feature request. Let's continue the discussion there?

[npm1]

Ok, closing this then, the discussion can continue in the crbug.