Provide a way to associate warnings with measurements

[gaearon]

Not sure if this is in scope of the API, but built-in browser timings can show potential perf bottlenecks in their UI:

I'd like to have a way to do the same with user timing. We need a way to highlight measurements that may not be long per se, but trigger cascading effects later (just like a reflow). For now, I am trying to emulate this with an emoji:

However I wish there was a standard way of attaching such meta information to the user timing. Then the browser could highlight problematic measurements differently and call attention to them even if they're not long.

[igrigorik]

We've discussed this before at length and closed it as a wont-fix, see #3.

That said, perhaps something we can revisit in context of w3c/charter-webperf#28..? :)

[gaearon]

I’m not proposing to associate arbitrary payloads with marks like in #3 per se because browsers then wouldn’t interpret generic userland payloads in any special way.

I’m proposing a way to mark measurements as needing attention, so that the browsers can implement a special way to display them (similar to what they already do for built-in events). If you don't consider DevTools to be one of primary use cases of User Timing API, this could also be useful in logs (think a severity field).

[eliperelman]

From what I can recall of previous conversations in Mozilla, there was a lot of pushback for using userland as informative for platform indicators. For devtooling I could see this as a possibility, but anything more than that is also likely to see pushback.

Also a little more context: #6

[gaearon]

To be clear, I’m not suggesting to expose platform indicators through User Timings. I only use the existing platform indicators as prior art for coupling measurements with warnings in a flame chart.

My use case is library-specific: we as a library want to flag certain User Timings measured by us as needing attention. They are not related to the platform, but to known bad patterns specific to our library. What we need is a mechanism to make some User Timings have greater severity so that the browsers can highlight them, and the user can notice them immediately from a large flame chart.

[igrigorik]

Do all the devtools vendors provide a ~consistent enum to indicate priority of different messages?

If you don't consider DevTools to be one of primary use cases of User Timing API

That's the crux of it.. When UT first came around, I don't think that was the goal. That said, now that CDT is showing UT, we've seen a big uptick in usage, and I think that's something we want to encourage. With that in mind, perhaps we ought to rethink and revisit if we consider DT to be a key customer.

/cc @toddreifsteck

[toddreifsteck]

FWIW, I assert that devs using dev tools ARE a key consumer. @nolanlawson and I currently evangelize the fact that user timing show up in dev tools as a key reason to use mark/measure rather than rolling a standalone solution.

At the same time, as @eliperelman suggests, we should NOT be adding a lot of dev tool-only goo to user land.

The concept of a severity is interesting, but... it seems that may be awkward to set at the time performance.mark or performance.measure are called. Would that also require the ability to new a mark/measure and insert it directly?

[npm1]

UserTiming L3 provides a detail field for marks and measures where you can store metadata. Integration with DevTools is a separate issue but I don't think 'severity' is a primitive we'd want to include. I propose closing this. Thoughts?

[igrigorik]

I'd love to get input from folks working on DevTools and some JS framework authors before we close this out. My hunch is that you are right and new detail field should address many of the previous requests, but there is still value in formalizing some common fields — using emoji's to signal warnings and severity is a clever hack, but I think we can do better.

I'll start a thread with some Chrome folks..

[yoavweiss]

I think that similarly to #68, this can be solved by the namespaces idea discussed in #86 (where devtools would highlight certain UT namespaces). Closing as a duplicate. Let's continue discussion on #68.