With React Natives performance being a hot issue on twitter, i see every expert out there mentioning ‘Measure, before and after — this tip isn’t applicable everywhere’ in some form. It’s definitely good advice, but also leaves the question: Well how? 🤷♂
The Low Tech Approach
This is especially useful when making macro decisions like changing out a component, choosing a library or applying a big rewrite.
Find your self the slowest phone that you support and start measuring things out — its simple and easy. Compared to simulators its considerably much less prone to CPU variations and a lot closer to what your user is actually dealing with.
- Test at least 3 times before and after to minimize variations and make it into a spread sheet.
- For the most reliable data, especially for things like start-up time, use the release variation of your build.
- Use the absolutely slowest device in the range you support, the performance differences will be bigger which in turn minimizes reaction time variations.
- If you’re dealing with smaller optimizations — use video capturing and set the two videos up side-by-side this will give you exact time codes.
The Nitty Gritty Approach
For day-to-day optimizations like asset optmization, redux and reworking component logic.
I highly recommend using jhen0409’s react native debugger, it combines
Most importantly it allows you to record your rendering tree and gives you a readable chart that shows exactly how many times and how long each component is rendered in your react tree.
Remember to test on a physical device! Testing directly in the simulator is much more convenient, but leaves too much CPU variations for proper comparable results.
The Future Proofing Approach
Your now working on a full fletched big production app, and you want to make sure everything stays fast
Using the detox can be extremely useful not only for automated gray box end-to-end testing, but also for measuring key performance statistics. You can set up a test suite that tests your highway functionality and on the way measure timecodes on each step.
Combining this with your CI/CD setup, to automatically be run on each pull request you can now set rules on how much performance may drop or improve, in a big project this is absolutely crucial to ensure your app will stay healthy and fast 🔥
Further reading and watching
👋 Hey! I’m Thomas Kjær-Rasmussen, frontend nerd and tech enthusiast. Hit me up on Twitter or below if you got any questions, comments or ideas!