[Feedback] Enhanced Traces experiment

[captainbrosset]

tl;dr: Enhanced Traces is a new experimental feature coming with Microsoft Edge 109 which we'd love your feedback about.

---

Context

The Performance and Memory tools record runtime data about your webpage. Exploring the recorded data makes it possible to improve your webpage's memory usage or runtime performance. Additionally, the recorded data can be exported to files on disk. The exported files are called traces.

Exporting performance and memory traces is useful when you want to share these files with other people to get help with investigating issues. An exported trace is a .json, .heapsnapshot, .heapprofile, or .heaptimeline file. An exported trace file can be imported in DevTools at any time. By default, traces contain minimal information about the runtime data from the traced webpage.

Starting with Microsoft Edge 109, traces can experimentally be exported in a new enhanced format.

What's an enhanced trace

An enhanced trace is a .devtools file that contains more runtime data from the traced webpage. Enhanced traces make it much easier to resolve performance and memory issues by recreating the environment in which the trace was recorded and by providing original source files. An enhanced trace contains the execution context and the list of parsed scripts, and can optionally contain console messages, script sources, and a snapshot of the DOM tree.

When an enhanced trace is imported in DevTools, a new DevTools window appears. This new window isn't connected to the webpage that's running in your browser, and instead re-creates the environment in which the trace was originally recorded.

For example, if a snapshot of the DOM was recorded in the enhanced trace, the Elements tool displays this snapshot. If console messages were recorded, the Console tool prints these messages. The Sources tool displays the scripts that were present during the recording.

Using enhanced traces makes it possible to reliably resolve source code references found in imported traces to the actual runtime code in the Sources tool. Additionally, if source maps were presents when a trace was recorded, it will also be possible to resolve code references to their original source code.

Feedback

We're actively experimenting with this new feature.

If you've used enhanced traces and have any feedback to share with us, please feel free to leave a comment here.

[paulirish]

This feature is a great idea and I really like the experience. 👍

WDYT about naming the property holding the trace events traceEvents rather than payload?

That'd be consistent with the typical trace JSON format, which is ~canonically{traceEvents: Array<TraceEvent>}.
about:tracing and Performance Insights both use {traceEvents: [], metadata: {}}, whereas Chromium DevTools Perf panel saves Array<TraceEvent> traces, but we're soon going to make it match.

An example usecase: currently https://trace.cafe doesn't work on enhanced traces, but with the above change it'd work (minus the enhancements;)

I'm not sure exactly the impact for the memory enhanced traces.. but, a property that's specific to them would help tools ingesting this data. (I can see the .meta.type prop differentiates, but the object shape being distinctive would assist.)

[captainbrosset]

Thanks @paulirish for the great feedback. Let me ping @bwalderman and @zoherghadyali here as they will, no doubt, be interested in this.

[robpaveza]

Thanks for the feedback @paulirish!

So I landed on the name payload because it doesn't fit for the memory data, which are not a series of events but rather a moderately self-describing object. (As you noted, the .meta.type property is what distinguishes these). I'm not particularly opposed to changing this, but we had designed this to be as straightforward as possible to use via CDP for customers who were already integrated with the performance and memory CDP API calls. (That having been said, I suppose that the shape could be changed moderately since the .meta.type property is set by the input parameters anyway).

Unfortunately I can't see your make-it-match link - even with my committer account I get "Permission denied". I'd love to know more!

[paulirish]

@robpaveza on the linked crbug.. I'll get back to you, the issue creator is OOO and I don't want to flip it to public without his consent. :) But the gist is that we're going to add basic metadata to traces saved from Perf Panel, and thus will almost certainly use the json format described above.

Aye, it's your call on the naming. I am just attracted to the idea that tools like traceviewer, perfetto, speedscope, spall could view these enhanced traces as well. I'm less familiar with the 3 memory profiles, but after looking at them, I don't see an obvious solution that'd net us some 'free' compatibility anywhere.

[jackfranklin]

Just opened up that Github link that Paul shared so hopefully you can see it now. The TLDR is that the performance panel currently doesn't save files in the way that Performance Insights and about:tracing does, and we would like them to match. There are no timeframes on this currently so I can promise any dates, but I think landing on the same format across all tools would make a lot of sense.