💡 More attribution data for event timings and core web vitals

[niallwingham]

The web-vitals reference implementation includes an attribution build with useful data.

Datadog includes some of this data but not all. For example, INP events have a selector path to the interaction target, but not the time the interaction happened or the current load state of the document. This would be helpful to have when diagnosing e.g. if an interaction is slow on its own, or if it just happened to be slow because the document was still loading.

(Given a single Datadog view with INP data, you can usually kinda tell by looking at the actions tab and the overall timeline. But it would be better to have it as actual data points on the view, so you could use them as a facet when searching and graphing.)

Based on the reference implementation, it looks like it's not too hard to implement (easy for me to say, ha). Some of this data is already available on the underlying PerformanceEventTiming and is just copied over. The load state needs to be cross referenced with a navigation timing.

Full documentation on web-vital's attribution data is here.

[niallwingham]

You could also consider giving even more data than web-vitals does.

For example I see #2696 related to soft navigation; and while I agree it's maybe a bit early to jump on that, you do already have this a bit with Views and loading_type = initial_load | route_change.

I might be interested in both "when did this event happen relative to the intial load" and "when did it happen relative to the most recent route_change" i.e. to the start of this view. (And if you think it's too confusing to include both, relative to the start of the view is probably the better one to pick imo!)

I don't know if you can go so far as to redetermine the load state of the document after route changes, but timing is maybe fine for now and still very helpful 🤷🏻