Add better performance metrics to Grafana

[roryabraham]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

See this predesign for some additional context.

Problem

We've got a sort of wonky set of performance metrics in Grafana right now. For example, we measure "Initial Homepage Render" as the time between AuthScreens.constructor being called and AuthScreens.componentDidMount being called. It's not clear what this metric really means or if it's indicative of anything real to the user.

As a result, the performance metrics we can measure

Solution

Build out a better, more accurate set of Performance metrics and start tracking them with Grafana. This could include:

• TTI (Time to interactive)
• LCP (Largest Contentful Paint)
• FID (First input delay)
• TBT (Total blocking time)
• Frustration index

Others? Of course, all these metrics should be tracked on a per-platform basis.

View all open jobs on GitHub

[roryabraham]

@hannojg Seems like maybe a good fit if you're interested?

[roryabraham]

I also think we agreed to nix Frustration Index because it's more complex and less actionable than other metrics here

[roryabraham]

Beyond just sending these metrics to a remote server, I think it would also be helpful to log these metrics locally to make it easier to benchmark individual PRs.

[hannojg]

Oh yeah, very interested, will add this to my tasks 💪

[roryabraham]

Taking this out of planning. It would be a somewhat big lift for us to make graphs.expensify.com public, so we should maybe just publish these metrics separately than our other Grafana graphs

[roryabraham]

Carved this out here as what I think should be one of @hannojg's top priorities. @hannojg if you're blocked on #11711, I'd recommend spending some time on this in the meantime.

[roryabraham]

@hannojg should we think about handing this off to someone else?

[hannojg]

We could, what is the priority on this one? From what I understand you are trying to heavily focus on bugs and performance issues right now, so I was prioritizing that so far (but it's still on my todo list)

[JmillsExpensify]

I posted a discussion in Slack on the priorities, though didn't add this one. I kind of think that helping any useful tests for our CI initiative is higher value – mainly because we are getting close to launching it but we only have one test at the moment.

[roryabraham]

I would say this is currently lower priority than bugs, but still quite valuable in the long-term because it helps give us a better objective framework to talk about performance, particularly for those of us that aren't as well-versed in the various performance testing and profiling tools there are out there for testing React/React Native/web/mobile apps.

[roryabraham]

Unassigning myself from this issue, because we completed the predesign and I'm not going to implement it myself.

[melvin-bot]

This issue has not been updated in over 15 days. @hannojg eroding to Monthly issue.

P.S. Is everyone reading this sure this is really a near-term priority? Be brave: if you disagree, go ahead and close it out. If someone disagrees, they'll reopen it, and if they don't: one less thing to do!

[hannojg]

I just created these two PRs:

• dev: measure app start TTI more accurately #13997
• Dev/ci perf test search #14044

With these changes we will send events with environment information to Grafana, which is super important to separate.
In addition to that it makes the TTI calculation more accurate.

In general we found that TTI is the main measurement that we want to take. Any other metrics aren't really appealing for mobile platforms.
There might be special performance for the web platforms.
However, the measurements we send to Grafana (TTIs for various flows), are mainly there to help us catch performance issues within the staging/production app (e.g. after new slow code got merged)

[MelvinBot]

@hannojg, this Monthly task hasn't been acted upon in 6 weeks; closing.

If you disagree, feel encouraged to reopen it -- but pick your least important issue to close instead.