Mobile Development 16 min read

Performance Optimization of React Native Pages in 58 App: Analysis and Solutions

This article analyzes the startup latency of React Native pages in the 58 real‑estate app, identifies bottlenecks such as bundle size, hot‑update and Java‑to‑JS bridge delays, and presents a series of optimization techniques—including bundle splitting, silent updates, on‑demand loading, and stepwise rendering—to achieve faster, more stable page launches.

58 Tech
58 Tech
58 Tech
Performance Optimization of React Native Pages in 58 App: Analysis and Solutions

Since introducing React‑Native in 58’s real‑estate business line, the app now serves over 30 modules, but RN page startup time lags behind native pages, prompting a systematic performance analysis.

Loading Process Analysis – The startup consists of initializing the RN environment, loading the framework JS (coreBundle), downloading the business JS (bizBundle), running the business JS, and rendering the page. Detailed log data from an Android device (Mi Mix 3) shows the time spent in each stage.

Problem Investigation – The most time‑consuming parts are hot‑update (≈130 ms), the Java‑to‑JS bridge (≈80 ms), and large bundle sizes caused by the WBAPP middleware and extensive use of react‑navigation.

Solutions – (1) Split bundles into coreBundle and bizBundle and preload coreBundle; (2) Use silent‑update with cache‑first strategy; (3) Apply incremental (diff) updates; (4) Reduce bundle size by on‑demand loading of WBAPP via babel-plugin-import ; (5) Move heavy imports (ReactNative.js, renderApplication.js) to coreBundle with __r('node_modules/react-native/...') ; (6) Optimize navigation by removing unnecessary react‑navigation layers or loading them lazily; (7) Cache data, split APIs, and render pages in steps (first‑screen priority, visible‑range rendering).

Optimization Effect – After applying the above measures, homepage launch time became stable across network conditions, non‑homepage pages saw a 300 ms reduction, cache hit rates reached 60‑90 %, and bundle size decreased from 364 KB to 249 KB for on‑demand modules.

Conclusion & Future Work – Although RN cannot fully match native startup speed, the gap is narrowed by encapsulating complex optimizations. Future plans include slimming public dependencies, postponing homepage business code, merging loading screens, and building a monitoring system for runtime latency.

References – React‑Native documentation, MobX issues, React‑Navigation guide, and a detailed 58‑APP development practice article.

Mobile Developmentperformance optimizationCacheAndroidReact NativeHot UpdateBundle Splitting
58 Tech
Written by

58 Tech

Official tech channel of 58, a platform for tech innovation, sharing, and communication.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.