Performance
Making a React Native app faster: startup, rendering and local data
Performance problems in production apps are rarely a single bug; more often, the app works but makes users wait. This article covers the areas I analyse, using two production apps: Khedmah Delivery, where typical opening time went from 7–8 seconds to 2–3 seconds, and SnapHatch, where reading from local data made startup about 20% faster.
Start with one journey and a number
Before changing anything, pick one specific journey: opening the app, loading a particular screen, scrolling a long list, or coming back from a weak connection. Measure it. Then you can compare the same thing afterwards, instead of working from a general feeling that the app is slow.
Take work off the startup path
Caching and API changes can stop startup from waiting on data the app already has, or doesn’t need for the first screen. That was the main change on Khedmah, and typical opening time dropped from 7–8 seconds to 2–3 seconds.
Stop re-rendering what didn’t change
Complex screens slow down when unrelated state changes update big parts of the component tree. Clearer state ownership, smaller components, focused subscriptions and fewer repeated calculations keep rendering close to what actually changed.
Show local data first
On a weak connection, local data makes startup faster and keeps useful screens available. Background sync can refresh it without blocking the user. On SnapHatch, this made startup about 20% faster.
Look at crash reports after every release
Crash reports are useful when they lead to a reproducible problem, a prioritised fix and a check after release. On Khedmah, Firebase showed crash-free sessions going from 90% to 100% over one measured three-month period.
Remember how fast it feels
People also judge speed by loading states, feedback and how quickly they can find the next thing to do. Event tracking and a round of design changes can show friction in the interface even when the requests themselves are fast enough.
Summary
- Pick the screen, device conditions and user action, and measure them.
- Trace the startup, state, rendering, API and local-data work around that journey.
- Prioritise by user impact, risk and whether you can measure the result.
- Make focused changes without disturbing behaviour that already works.
- Measure the same journey again, and keep watching stability after release.
None of these results came from a single fix. Startup work, API behaviour, local data, rendering and monitoring each contributed, and consistent before-and-after measurement made the improvements verifiable.