I think this proposal is a fantastic idea and would definitely be something we (a RUM vendor) would be interested in capturing for our customers if available. Attribution of potential performance issues seen in first- and third-party scripts is on the minds of a lot of our customers.
name attribution proposal seems reasonable.
Assuming this probably wouldn’t be tracked proactively, but only “captured” when turned on via
PerformanceObserver, correct? Unlike ResourceTiming, which I would argue is more important to have everything captured even if no one is listening (up to 150 limit or everything before
onload) to be able to generate complete picture of for a Waterfall (so a RUM script doesn’t need to be sync loaded in the HEAD), this seems like it should only be captured if the page is specifically requesting it, and long tasks that happened prior to it being turned on are just lost.
While I think Philip’s note that a completely locked-up page might not be able to deliver these events is an important point, I think that’s an case extreme case – and maybe could be solved by something similar to Network Error Logging (“Page Freeze Logging”).
The data we would get out of this proposal from all of the various little Long Tasks on a page will be very useful.