As a side note, we've been using miniprofiler[0] for a long while now, and it has some limitations, but can be very useful some times.
As a side note, we've been using miniprofiler[0] for a long while now, and it has some limitations, but can be very useful some times.
I'll see if there's anything we can do on our side (I'm the DevTools tech writer), but I think it's an API limitation. We might be able to use some arbitrary convention in the timing values that let's us plot along a time series...
[1] https://camo.githubusercontent.com/bc62621acd195d11d0247c0cc...
Author here - I believe that's the case. There isn't a way to specific start & end time: https://w3c.github.io/server-timing/#dom-performanceserverti...
That said, the spec also mentions:
> To minimize the HTTP overhead the provided names and descriptions should be kept as short as possible - e.g. use abbreviations and omit optional values where possible.
I could see significant issues if we tried to send data in timeline fashion (such as creating a metric for each database record call in an N+1 scenario).
One idea: pass down an URI (ie - https://scoutapp.com/r/ID) that when clicked, provides full trace information.