WhoBuilt

User-Focused Performance Tracking

Jun 4, 2025· 14 min· 473 views·Watch on YouTube

Speaker

Tim Golen of Expensify discusses user-focused performance tracking at the React Universe Meetup, hosted by Callstack.

Why measure performance for users

Golen says speed shapes how premium an app feels, and users are the stakeholders most affected by performance. He argues that user champions can drive word of mouth and loyalty. A vague goal to keep all interactions under 100 milliseconds raised questions about which interactions mattered and why that threshold was chosen.

Choose interactions that matter

Golen reviews approaches from Shopify and Coinbase. Shopify wraps components to measure render time, but he says doubling the component tree was too costly for Expensify’s large app. Coinbase tracks app render completion and navigation blocking time; Expensify adopted a similar focus on a smaller set of key interactions.

Measure what users notice

Golen’s rules are to quantify performance and focus on changes users can notice. Expensify tracks app startup and opening chats from the main navigation, a preview, or a thread, including the 50th and 90th percentiles. The team also counts error pages and is interested in measuring total time spent on loading skeletons.

Track results and improve iteratively

Expensify segments measurements by environment, app version, and platform, using StatsD and Grafana. The team shares weekly reports, establishes thresholds from a baseline, and creates assigned issues when metrics cross them. Golen says faster builds, from 25 minutes to 7 seconds 90% of the time with the React Native Enterprise Framework, could also help teams catch performance regressions in pull requests.

Takeaways

  • Choose a small set of user-visible interactions to track instead of measuring everything.
  • Quantify performance changes before optimizing; code that looks inefficient may not affect users.
  • Track P50 and P90 by environment, version, and platform to spot regressions.
  • Use a baseline and agreed thresholds to turn weekly metrics into assigned fixes.
  • Shorter build times can make it practical to check for performance regressions on every pull request.

Mentioned in this talk

Search inside this talk

What was claimed 15

Related talks