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.
>
> http://githubengineering.com/browser-monitoring-for-github-com/
>
Being able to render a graph like this would be quite valuable as well.
{F189345}
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).
### High-level plan
From T104902#3253227, and T104902#3746563:
* {icon check color=green} Server will not filter out zero values.
* {icon check color=green} Server will not exclude values based on an upper bound. – T104902#3746563
* {icon check color=green} Server will apply remaining filters to entire events, not individual values. If one of the values is invalid, discard the event as a whole.
* {icon check color=green} Server will record values to Graphite as relative to fetchStart, instead of navigationStart.
* {icon check color=green} Server will introduce new metrics for deltas, to make stacking more accurate. (e.g. "dns", "request", "response", etc. in addition to dnsStart/End, requestStart/End, etc.)
* [ ] (Last step) Clean up client-side code to only send what's needed for navtiming2.
### frontend.navtiming2 issues
* [ ] Stacked values don't match the total from loadEventEnd – T178479
* [ ] "dns" is usually zero? – T178479#3699302
* [ ] "unload" correctness – T178479
* [ ] "redirecting" correctness – T178479
* [x] Make sure mediaWikiLoadEnd or mediaWikiLoadComplete is working - T180598