How We Cut React Native Cold Start from 1.78 s to 0.8 s: A Four‑Step Optimization Journey

Background and Problem

In 2021 a solution called “58RN page instant‑open” reduced first‑screen latency but on a low‑end device (Pixel 3a) the cold start still took 1.78 s (hot start 1.10 s) with a noticeable white screen. User‑experience data shows that each second shaved from first‑screen time reduces churn by roughly 6.9 %.

Profiling the Startup Chain

Instrumentation at key points (route entry, initialization, container creation, code loading, UI visible) measured a total cold‑start cost of 1787 ms. 88.3 % of this time is spent inside the React‑Native framework (JS engine start, bundle parsing, first‑screen render). An idle gap of 379 ms exists between route entry and RN initialization.

Four‑Step Progressive Optimization

1. Advance Initialization Timing – Cut 379 ms Idle

Problem: The original logic triggered RN initialization in onResume, causing ~400 ms of idle time before the framework could start.

Solution: Move the initialization to the page‑creation phase so RN starts before onResume, eliminating the idle gap.

2. Preload Basic Resources – Prepare Ammo

Problem: Each start loads native libraries, initializes the framework and unpacks resources, costing about 50 ms.

Solution: Perform these tasks asynchronously in the background during app launch and reuse the results when the RN page is entered.

3. Container Reuse – Create Once, Use Many Times

Problem: Opening the same page again recreated the RN container, adding ~200 ms.

Solution: Cache the container after the first creation and reuse it on subsequent navigations.

4. Container Preloading – Have the Container Ready Before Click

Problem: Reuse only helps the second open; the first open still incurs ~200 ms for container creation.

Solution: After app launch, background‑pre‑create a full RN container (instance + runtime + business code) and store it in a warm cache. When the user first navigates, the ready container is used immediately, shifting the 200 ms from the critical path to idle time.

Pitfalls Introduced by Container Reuse and Fixes

Back‑button ineffective: The preloaded container has no page context, so the back‑button callback is empty. Fix: Inject the correct back‑button callback when the page becomes visible.

Route parameter mismatch: Parameters are injected only on the first container creation and are not refreshed on reuse. Fix: Use a global parameter manager that refreshes parameters each time the page becomes visible; RN fetches the latest values via the Bridge before code execution.

Hot‑update code not effective: Reused containers load the bundle only once during the initial creation. Fix: After a hot‑update, set a flag; on the next open, detect the flag, rebuild the runtime environment, and reload the new bundle.

Missing native modules during preload: Some native modules depend on runtime callbacks that are unavailable during preload. Fix: Register all modules with placeholder callbacks during preload, then replace them with real callbacks at runtime.

Global state cleanup issues: Reused containers persist, and some components clear global state on view unmount. Fix: Move state from a global store to the view instance; initialise on creation and clean only the instance’s own state on destruction.

Internationalisation not refreshing: The i18n module is loaded once in the reused container and never refreshed. Fix: Fetch the latest language on page visibility and re‑initialise the i18n module.

Results

The optimisations reduced cold‑start time from 1.78 s to 0.80 s (‑55 %) and hot‑start time from 1.10 s to 0.33 s (‑70 %).

Future Work

Further improvements include Hermes byte‑code pre‑compilation, Fabric + TurboModules for synchronous communication and on‑demand initialization, and behavior‑driven smart preloading.