You can go EVERYWHERE but I can go FAST - performance case study

Binda recommends removing dead or legacy code, avoiding large bundled JSON files such as translations, and removing or replacing unused third-party libraries. In one project, reducing the bundle from 28 MB to about 15 MB improved download time by 26%, execution time by 10%, and time to interactive by about 13%.

Components should use fewer device resources and render only as often as needed. Profiling showed a shimmer component took 132 ms because its library included unused logic; replacing it with lighter primitives reduced render time to 36 ms and simplified its structure.

Binda uses Flipper flame charts to spot slow component structures and unexpected renders. In one case, moving internal state higher in the component tree cut the structure from 38 components to 20 and prevented three extra renders. In another, changing how a Hook-driven prop was passed stopped off-screen FlatList rows from re-rendering; average JS FPS rose from 37 to 55, and the performance score increased from 80 to 95.

For meaningful measurements, Binda recommends using release builds for both the native app and the JavaScript bundle, since development and mixed build setups can distort results. He argues that improving an existing app can be costly, so teams should balance flexibility with the speed users need. His measurement advice is to establish a baseline, use a reliable method, and combine a broad view with attention to details.