Most of the required parts for this are already in place but @Peter and I found it somewhat untrustworthy.
Some metrics are missing, some are transformed to relative offsets between two points, some are aggregated, some zero values are ignored in questionable ways. It's hard to get a complete picture.
>>! From T104902#1626842 with @Peter:
> * Move to deltas and "start" values for our metrics.
> * Have the server fragment our frontend properties by browser_family using the ua-parser library server-side. We can wildcard over this for general graphs, but it allows us to draw a more realistic picture for individual browsers (and help pinpoint problems with specific browsers), since median of everything is not very representative of real users.
> * Don't ignore non-compliant browsers that report properties out of order. Even quite recently Firefox and Chrome have both had bugs with compliancy. (e.g. https://bugzilla.mozilla.org/1123920). So if the browser is non-compliant, we'd emit some kind light-weight error increment beacon. Perhaps with statsv. This will help us keep track of how much data we're excluding.
>>! In T99060#1299940, @ori wrote:
> An idea from GitHub's engineering blog: use a stacked graph to represent navigation timing metric.
Being able to render a graph like this would be quite valuable as well.
And to have the dashboard feature sub-views for individual browsers because the overall picture is somewhat skewed as it is based on medians of individual properties. It does not represent the experience of any individual user (per se).
* [x] Server will not filter out zero values.
* [x] Server will filter out events instead of individual values. If one of the values is above the threshold, discard it entirely.
* [x] Server will report absolute values relative to fetchStart instead of navigationStart.
* [x] Server will also compute deltas and report them to Graphite.
* [ ] (Final optimisation) Clean up client-side code to only send what's needed for navtiming2.