Make use of new Chrome performance measurement APIs?

[danielcompton]

I'm not sure what/how we might use these, but they might be worth looking at a bit later in the summer. https://developers.google.com/web/updates/2017/06/user-centric-performance-metrics

[danielcompton]

https://calendar.perfplanet.com/2017/tracking-cpu-with-long-tasks-api/
https://www.html5rocks.com/en/tutorials/webperformance/usertiming/

[mike-thompson-day8]

Better interaction with the chrome profile API.
See also console.timeStamp([label])

[mike-thompson-day8]

Closing — superseded by day8/re-frame#840 ("Bridge re-frame's trace timing into the User Timing API for in-DevTools profiling").

The 2017 framing here was "use Chrome's perf APIs" without a concrete shape. Eight years on, the right shape is clearer: re-frame's trace stream already carries high-resolution timing for every event/sub/fx/render — what's missing is publishing that timing into the W3C User Timing API so it interleaves with browser-native paint/layout/network/GC events on a single timeline in DevTools' Performance panel.

The new issue:

• Lives on re-frame (not 10x) — it's a generic capability for any re-frame consumer; 10x's role would just be a settings toggle that calls (re-frame.devtools.perf/enable!).
• Names the structured label shape (rf:event:cart/apply-coupon, rf:sub:cart/total, rf:render:re-com.box[cart/view.cljs:84], etc.) — including {:file :line} source coords from re-frame.core-instrumented when present.
• Lights up beyond Chrome — User Timing is a W3C standard; works in Firefox / Safari / Lighthouse / any PerformanceObserver consumer.
• Is opt-in (no overhead by default), with periodic flush so the marks list doesn't grow unbounded.

See day8/re-frame#840 for the full proposal.