The UI Was Beautiful. The Frame Rate Wasn’t. Why We Didn’t Fix It.
summary
A migration to React Native yields a beautiful UI that still produces dropped frames; dashboards (DataDog/Sentry) reveal high CPU, high memory, and dispersed long JS-thread tasks rather than one big render bottleneck. Fixes include removing an SVG shadow package, capping map pins, caching disk-read headers to cut API round trips, and shaving milliseconds across many hotspots. A one-month deadline exposes that Android time to full display = 5s and that performance requires product metrics not gut feeling and repeated small wins.
AI-written summary · about
chapters (12)
- 0:00Introduction
- 1:36React Native migration issues
- 3:01UX vs performance balance
- 5:51Lower-end device issues
- 7:58Android performance complaints
- 9:22Limited time performance fixes
- 10:44Key performance metrics
- 12:30Slow home screen on Android
- 14:57Small bottlenecks found
- 16:42When performance is enough
- 18:24Why performance matters
- 20:11Rethinking performance approach
related talks
26mMeasuring and Improving React Native Performance
24mOptimising React Native "Tools and Tips"
39mPerformance issues: the usual suspects
23mPractical Performance for React Native
21mWanna get rid of UI Jank?
24mThe Performance Myths of React Native apps
07mDebugging RN Android Performance
43mNo More Jank: Escaping the Matrix of Frame Drops