Add a non-normative format for the detail param that allows developers to customize the presentation of timings in devtools

[and-oli]

In Chrome DevTools 128 we launched a mechanism for extending the DevTools Performance panel by defining a format for the detail param of performance measures and marks (official docs are WIP and will be publicly available once Chrome 128 is a stable version, around August 22nd this year).

Specifically, developers can define the value of the detail param to be an object with a devtools property containing parameters to customize the way the timing / mark is presented in the timeline view. For example, a track param can be passed to customize the swimlane in the timeline view in which the timing will be added; a color to customize the color, etc. For example:

performance.measure('myCustomMeasure', 'startMark', 'endMark', {
  detail: {
    devtools: {
      track: 'The name of the track', 
      color: 'primary',
    }
  }
});

Implementing user timings for the purpose of adding data to the Performance devtool is a common pattern in the ecosystem and we decided to implement this customizing feature after reviewing several feature requests for doing this with user timings, for example: #109 , #69, #25. We also expect to extend the list of customizable presentation attributes in the near future.

We've proposed frameworks like Angular and React to adopt this format to improve the DX of devs that use these frameworks, and have received positive feedback. (See angular/angular#55805 and facebook/react#29231).

We believe that it would be beneficial for the web ecosystem if other browsers devtools supported customizability of their performance tool using this format. For example, it would allow for a better experience when developing with frameworks (granted frameworks adopt the format in the first place, which would be more likely if it's standardized to some degree), but also a way to visualize an app's custom instrumentation in the context of the browser performance tool is a valuable feature in itself.

Given the arbitrary nature of the detail param and the fact that the data presentation is an implementation detail, this feature is ideally defined as non-normative.

[clelland]

This looks like it could be considered in conjunction with w3c/long-animation-frames#3, which discusses a similar method to annotate devtools with custom tracks.